User talk:Dalba

Archives

---

1

Citer / vauthors

Citer's great, and it would be cool to have a vauthors option to generate author names in Vancouver style, since this is what (on en.wikipedia.org anyway) is usual for biomedical citations. Bon courage (talk) 07:14, 1 August 2024 (UTC)

Thanks for the suggestion! I believe the main (if not only) difference is that authors should be added to the vauthors= parameter. If that's the case, it shouldn't be too difficult to implement. However, I'll need to rework some parts of the code, which might take some time. No promises, but I'll definitely look into it. Dalba 14:52, 2 August 2024 (UTC)

Localization

Hello Dalba

Your tool “Citer” is excellent and several active users on the Danish Wikipedia (dawiki) use it. However, there are some language issues, so I would like to ask if you want to do more localization.

There are two aspects to this:

1. It would be good if the output in the form of template calls could use Danish templates and template parameters as well as Danish language dates.
2. It would also be good if the tool understood Danish dates on websites and Danish keywords in bylines etc. This would also benefit contributors on other Wikipedias that use Danish-language sources.

It would be ideal if the program could be modified so that users with different languages could contribute translations from their own language. I hope you will consider this. Thank you for your attention. Sincerely, --Dipsacus fullonum (talk) 18:39, 17 December 2024 (UTC)

Thank you for your kind words about Citer and for reaching out with this request. I'm delighted to hear that it's proving useful to the Danish Wikipedia community.

I understand the desire for improved language support. However, implementing full localization as you've described would unfortunately require a significant amount of development time and a substantial refactoring of the current codebase. This would involve establishing a system for coordinating and managing community-contributed translations and updates.

Due to other commitments, I currently lack the capacity to undertake the significant development work required for this feature. I will revisit this in the future should my availability increase. Dalba 05:15, 26 December 2024 (UTC)

Suggestion to include tweeter template

It would be very helpful if citer support {{Cite tweet}} from any x.com or tweeter.com link.--KEmel49 (talk) 09:10, 5 January 2025 (UTC)

I love the idea. I played around with it a bit, but X has done a great job of obfuscating its source code, and I couldn't find any free and open-source libraries for interacting with it. Dalba 16:17, 24 January 2025 (UTC)

@Dalba, I have no expertise on technical field, but i think it could be possible and only problem would be the |title= field.––KEmel49 (talk) 04:52, 25 January 2025 (UTC)

Incorrect dates for FDA

Citer is using the wrong dates for many pages from the FDA. It is using "1 October 2024". Here are some examples.

"Vitamin K Substances and Animal Feed". U.S. Food and Drug Administration. 1 October 2024. Retrieved 8 January 2025. 

"Considerations for the Use of Artificial Intelligence". U.S. Food and Drug Administration. 1 October 2024. Retrieved 8 January 2025. 

"FDA approves nivolumab and hyaluronidase-nvhy for subcutaneous injecti". U.S. Food and Drug Administration. 1 October 2024. Retrieved 8 January 2025. 

--Whywhenwhohow (talk) 04:20, 8 January 2025 (UTC)

Hi, sorry for the late reply. Here's how Citer works: it tries to find a reliable date tag on a page. If that fails, it attempts to locate the first date on the page. The second approach is, of course, prone to errors, but it usually works well on most news websites and seems preferable to not providing a date at all. On the FDA site, there is an official date tag (<meta property="article:published_time" content="Wed, 01/22/2025 - 14:17" />), but it uses an ambiguous date format, so Citer ignores it. The DD/MM/YYYY format is ambiguous because it can be mistaken for MM/DD/YYYY. In this particular case, the ambiguity could be resolved because the month number cannot be greater than 12, so there's room for improvement. I just don't know when I get the time to do so. Dalba 16:13, 24 January 2025 (UTC)

Incorrect use of Journal for the FDA website

Here is an example

Research, Center for Drug Evaluation and (22 January 2025). "FDA adds Boxed Warning about a rare but serious allergic reaction called anaphylaxis with the multiple sclerosis medicine glatiramer acetate (Copaxone, Glatopa)". FDA. Retrieved 23 January 2025. 

--Whywhenwhohow (talk) 04:26, 23 January 2025 (UTC)

The webpage describes itself as an "article." In my past experience, "cite journal" has been the best choice for most items using "article" as their citation type. I see how it has been a poor guess in this case. Dalba 16:27, 24 January 2025 (UTC)

Issue with InDaily

An issue with the websites related to InDaily (and I think all Solstice Media?)... it does not seem to pick up the authors, since they changed their website design. It also always seems to pick up the website as "website=InDaily, Inside South Australia", and it would be good to drop that second bit.

Btw the date issue seems to continue with all articles published in the Australian morning (have not tested for exact time), using the previous day's date. I know you have looked at this before, but is there not some way of correcting this, please? Laterthanyouthink (talk) 02:19, 19 January 2026 (UTC)

I’ve updated the configuration for Citer to drop 'Inside South Australia' from the website name. This change hasn't been deployed yet, but it should be live within the next 24 hours.

Regarding the other points:

• Author Metadata: Since the redesign, the site isn't properly tagging authors in the metadata. While I could technically write a custom scraper to find them, it’s a significant amount of effort for a single domain. For now, it’s likely a manual fix for the user.
• The Date Issue: This usually comes down to timezone discrepancies. Because many websites don't explicitly state their timezone in the code, the tool pulls the date as provided by the server. To 'correct' this automatically, I would need to collect user timezone data, which raises privacy concerns I'd rather avoid. In most cases, the provided date is technically accurate to the source’s publication window.

I appreciate you keeping an eye on these edge cases! Dalba 06:33, 11 February 2026 (UTC)

OCLC

All OCLC's give HTTPError. Grimes2 (talk) 15:36, 12 February 2026 (UTC)

Another case of Toolforge's IP address being blocked. I've added Citoid as a fallback for OCLC failures; it should now generate a basic {{cite web}} template, which is hopefully better than nothing. Unfortunately, there isn’t much more I can do on my end when the IP is blocked. Dalba 15:05, 13 February 2026 (UTC)

Worldcat, my source for OCLC's, uses a captcha and requires registration. Bad! Grimes2 (talk) 19:55, 13 February 2026 (UTC)

George P. Smith, Nobel Laureate in Chemistry

When creating a citation for George P. Smith George Smith (chemist), using the biography from the Nobel Prize organization website, the returned URL says the URL date coincides with the laureate's date of birth. Odd. I would have thought it would be no earlier than November 2018.

Turtlens (talk) 19:52, 10 March 2026 (UTC)

Good catch, Turtlens.

That happens when a page lacks a proper publication date. Citer desperately grabs any date it finds on the page — here, George Smith's birth date — rather than leaving the field empty. A wrong date is easy to delete or fix; a missing date is easy to forget.

Not ideal, but deliberate. Thanks for the report. Dalba 09:57, 29 May 2026 (UTC)

References

New York Times doesn't include the 'website' parameter

Hi. I've noticed that when submitting a New York Times link, the website parameter is missing. This behavior is recent. As far as I can tell, the script works well in all other links.

Thank you for this wonderful tool. Cheers! Itzcuauhtli11 (talk) 14:25, 7 July 2026 (UTC)

Hi, thanks, and sorry for the late response. There has probably been a change on the NYT website. I'll look into it—I'm just too busy these days. It might take me another week or two. Dalba 17:58, 24 July 2026 (UTC)

I got to check it today. NYTimes is returning HTTP Error 403. It seems like a case of the server blocking Toolforge IP addresses. This can't be fixed on our end. After that, Citer falls back to using Citoid, which may lack some of the information that Citer usually gathers—including the website parameter in this case. Dalba 03:16, 30 July 2026 (UTC)

citer not responding to ISBN

I've tried citer on several ISBNs recently, and citer just ignores them. E.g.

Remarkable Bright Creatures ISBN-13 ‏ : ‎ 978-0063204157

It's not that I'm looking to cite Remarkable Bright Creatures. I chose that as an ISBN where the tool should work. Turtlens (talk) 17:22, 19 July 2026 (UTC)

The issue of the error not being shown should be fixed now. Thanks for reporting. The main issue is that Citer cannot find this particular ISBN. I might look for other sources later if I get the time to do so. Dalba 17:53, 24 July 2026 (UTC)

Citer not working

Like the person above, citer isn't responding to ISBNs, and when I try to input OCLC numbers it just outputs a web citation to the worldcat library entry. Ioe bidome (talk) 23:08, 4 August 2026 (UTC)

Remembering defaults of users

Wondering if we can have the tool remember the "date format" and "Pipe spacing" a user has previously choosen? Also wondering about integrating this into Citoid, as it works more often than Citoid dose. Started that discussion here. Additionally would be nice if we could generate "Cite news" templates. Not just "cite web". Best Doc James (talk · contribs · email) 16:38, 3 September 2026 (UTC)

Thanks for the suggestions!

Regarding remembering the date format and pipe spacing, Citer should already remember these choices for a user. There is one exception: when Citer is opened through a URL that explicitly specifies dateformat and/or pipeformat, those parameters temporarily override the user's saved preferences for that page. For example, the URL in your comment specifies both formats. The override remains in effect until the user chooses another format. So I think this part should already be covered, although I can certainly look into whether the current behavior is confusing or could be improved.

Regarding cite news, I'm not sure there is much to gain from adding it as a separate option. The documentation says that, since 2016, cite web and cite news produce exactly the same output when given the same valid parameters. The remaining differences are essentially that cite news can be used without a URL and accepts issue and volume.

The difficult part would therefore be determining a reliable, programmable characteristic that tells Citer when a source should be considered a news source rather than a web source. Even if we find such a characteristic, for the typical online sources Citer handles, changing cite web to cite news would not change the resulting citation. I'm not sure that makes the additional complexity worthwhile unless there is a particular use case I'm missing.

As for Citoid integration, I'm not quite sure what kind of integration you have in mind. Citer already uses Citoid's results in some situations, particularly when it has difficulty accessing a web resource directly. If the idea is instead to have Citoid use Citer as an alternative/fallback, that would probably be more complicated. Citoid and Citer are implemented in different languages, and I suspect the Citoid developers would prefer implementing specific missing functionality directly in Citoid rather than introducing a dependency on Citer. This is also somewhat outside my area of expertise, since I'm not very familiar with Node.js/Citoid development. Dalba 02:25, 4 September 2026 (UTC)

Thanks. Wondering if we could have the "dropdown" with url/PMID/OCLC be 4 buttons side by side.

It would make selecting one easier as one can be selected with a single click rather than multiple clicks.

What about integrating this into the en:Wikipedia:RefToolbar/2.0?

Basically your tool works for most news source and citoid/zotoro does not. See collection [1]

Yes the idea is to have citer as a fallback to citoid. The Citoid folks are unable to solve the missing functionality they have. Doc James (talk · contribs · email) 18:00, 14 September 2026 (UTC)

Thanks!

Regarding the four buttons, that's now done as suggested — URL, PMID, OCLC, and the other options are displayed side by side, so each can be selected with a single click.

Regarding integrating Citer into en:Wikipedia/2.0, I'm not entirely sure yet what would be involved. It would probably require some work on my side, such as implementing Citoid's output format so that RefToolbar can consume Citer's results in the same way. However, there are a couple of larger questions.

First, I'm concerned that Citer's current infrastructure probably wouldn't be able to handle the amount of traffic that RefToolbar could generate if Citer became available to RefToolbar users broadly. RefToolbar is already used on many Wikipedias, so this could be a very substantial increase in requests. I'm worried that we could end up in a situation similar to the current problems with Citoid, where the increased traffic from Wikimedia results in Citer getting blocked by some websites as well. :)

Second, I think this would need to be coordinated with the RefToolbar developers rather than being something I could add independently. I'm not sure whether they would be interested in or comfortable with such a change, and there may also be security or other architectural considerations on their side.

As for using Citer as a fallback for Citoid, I'm not sure whether RefToolbar currently provides any configuration or extension point for adding a third-party citation resolver (I suspect not; and without that, I don't see how this would work). If it does, and there is documentation describing how to do that, I could take a look at it sometime. Even if such an option exists, there would still need to be some changes on the Citer side to make it compatible. Dalba 10:29, 18 September 2026 (UTC)

Thanks. This ref is not generating a citation https://apnews.com/article/jehovahs-witnesses-donated-blood-transfusions-plasma-13fbe733e0039109efa728f65c7e4fda Thoughts? Doc James (talk · contribs · email) 19:01, 19 September 2026 (UTC)

Thanks for reporting this. I checked the URL, and when Citer's resolver requests it from Toolforge, AP News responds with:

HTTPError('HTTP Error 403: ')

So in this case Citer is being blocked by the site rather than failing to parse the page. Dalba 08:55, 25 September 2026 (UTC)

Do you have thoughts on the best way around these sorts of blocks? Could these requests be sent from a person's browser/IP address to get around the Toolforge block? Doc James (talk · contribs · email) 15:51, 25 September 2026 (UTC)

By the way does citer have an API? Also how does it figure out the reference meta data? With respect to integrating with the reftoolbar, I was thinking another button on the bottom beside "Reset form" that says "Citer" and when clicked, sends the url to citer to pull the details hopefully via an API. Was thinking this could be implemented as a user script initially so volume would be low. Doc James (talk · contribs · email) 20:16, 19 September 2026 (UTC)

Citer has something API-like, although it isn't documented as a public API yet. You can consider the current POST interface an internal API used by the web UI, and it could be extended to accept requests from other clients.

The web interface currently sends a JSON POST to https://citer.toolforge.org/, roughly like:

{ "user_input": "https://example.com/article", "input_type": "", "dateformat": "%Y-%m-%d", "pipeformat": " | " }

and gets back a JSON array containing the short citation, full citation, and <ref> tag, roughly:

[ "Short citation", "Full citation", "<ref>...</ref>" ]

There is also an html input type that accepts a URL together with HTML already fetched by the client, so Citer doesn't have to fetch the page itself. That could be useful for a browser extension, for example, when the site blocks requests from Toolforge.

For the metadata, Citer fetches web pages and extracts the relevant metadata from their HTML, while other input types use various external resolvers/data sources.

For the Reftoolbar/userscript idea, the existing POST interface could probably serve as a starting point. Citer doesn't currently expose a Citoid-style metadata API, though; that might be a more useful interface for Reftoolbar than having it depend directly on Citer's current formatted response. I could work on adding that format if there is real interest in it and someone is willing to work on the Reftoolbar side. Dalba 09:01, 25 September 2026 (UTC)

Thanks for these details. Will discuss with User:Yaron K. about potential next steps. Doc James (talk · contribs · email) 15:48, 25 September 2026 (UTC)

Interface improvements. Thank you.

Not a question or problem (yet).

I think your interface improvements are just what your user base was hoping for.

Thanks very much. Turtlens (talk) 18:24, 21 September 2026 (UTC)

input:doi for book chapter - output gave chapter = book title

No idea if this is widespread, but for ODNB doi 10.1093/ref:odnb/35119, citer output title=The Oxford Dictionary of National Biography |chapter=The Oxford Dictionary of National Biography, whereas using doi directly gives (chapter=) Morris, William Richard, Viscount Nuffield (1877–1963). Subscription is required for access to ODNB chapter.

I'm just cleaning up some wikipedia references, so not a major impediment to my day. Turtlens (talk) 21:10, 9 October 2026 (UTC)

This appears to be caused by the metadata returned by Citoid. For this DOI, Citoid identifies the item as a bookSection and returns the same value, The Oxford Dictionary of National Biography, for both title and bookTitle. Citer maps these fields to chapter and title, respectively, producing the duplicate.

Crossref's metadata for the DOI also lacks the actual chapter title, Morris, William Richard, Viscount Nuffield (1877–1963). I don't see a reliable way for Citer to distinguish this case from legitimate cases where a chapter and its containing book have the same title. Suppressing the chapter whenever the two values match could therefore break valid use cases.

Unfortunately, I don't see a good general workaround that Citer could implement without risking incorrect citations, so this will have to remain as is.

For reference, Citoid's output can be viewed here. Dalba 11:41, 12 October 2026 (UTC)

JSTOR bug in recent Citer

Hi, recently when I've been using Citer with jstor it hasn't actually been processing any of the citation metadata - to give a specific example in case it's just on my end, this one is outputting:

• {{cite |title= |jstor=44376579 |ref={{sfnref|Anon.}}}}

and not any of the actual citation information.

Thanks, ScalarFactor (talk) 00:02, 18 October 2026 (UTC)

Hi! Fixed Dalba 12:05, 18 October 2026 (UTC)

Thank you! ScalarFactor (talk) 18:34, 18 October 2026 (UTC)

I can't access citer.toolforge.org

Chrome show citer.toolforge.org is taking too long to respond and ERR_TIMED_OUT.--日期20220626 (talk) 03:18, 21 October 2026 (UTC)

Is this reason[2]?--日期20220626 (talk) 03:21, 21 October 2026 (UTC)

Hi, due to recent security issues, all toolforge tools are down AFAIK. Dalba 03:31, 21 October 2026 (UTC)

Yes, that is it. Dalba 03:31, 21 October 2026 (UTC)