Talk:Citoid

Jump to: navigation, search

About this board

Previous archives are at /Archive 1

Ghybu (talkcontribs)

Hello, I would like to activate it on ku.wikipedia. Apart from creating this page, is there anything else to do?

Mvolz (WMF) (talkcontribs)
Whatamidoing (WMF) (talkcontribs)

@Ghybu, are you making progress? Do you need help?

I noticed that no citation templates are visible under the "Manual" tab. Do you want to add some, or does ku.wikipedia.org prefer non-templates?

Ghybu (talkcontribs)

Indeed, I don't understand why it is empty. I also tested TemplateData and it works correctly. I missed something or I have to report a bug on Phabricator?

Mvolz (WMF) (talkcontribs)

Hi, for the citations templates to be visible under the "Manual" tab, that is actually a separate configuration message called the citation tool: VisualEditor/Citation tool

Ghybu (talkcontribs)

@Mvolz (WMF): Thank you for your help, it works now :)

Whatamidoing (WMF) (talkcontribs)

Yay! Thanks for the update. I'm glad that you got it all sorted out.

2604:2000:DD4D:3A00:B9DF:24AD:C67C:9115 (talkcontribs)

Is there a way for Citoid to work with a local database so that it doesn't need to go through Zoltero.

Whatamidoing (WMF) (talkcontribs)

I think the correct answer is: "Yes – theoretically". I think you would have to re-write parts of the software (so it could find and understand your local database).

Mvolz (WMF) (talkcontribs)

So, there is no database with citoid OR Zotero's translation-server. Both Zotero and citoid generate citations on the fly, by querying APIs (like crossref) and scraping metadata from websites.

You CAN use citoid locally without setting up a local Zotero translation-server instance. However, it won't work as well. Configuration options to use or not use zotero are in config.yaml

Reply to "Local database"
Summary by Sasuke Sarutobi

FDMS4 provided link to troubleshooter, which contained the information required to build support.

Sasuke Sarutobi (talkcontribs)

Citoid is currently unable to automatically fetch citation information from URLs for the London Gazette, which is the UK newspaper of record. Looking at a sample article, I suspect that it may be that a lot of the metadata for the article itself is in the body of the page, rather than the head, but it is tagged as metadata.

For example, https://www.thegazette.co.uk/London/issue/35586/page/2475 contains the metadata section of:

<dl class="metadata" id="pdf-description">
                                 <dt>Publication date:</dt>
                                 <dd>
                                    <time datetime="1942-06-05">5 June 1942</time>
                                 </dd>
                                 <dt>Issue:</dt>
                                 <dd id="issue-number">35586</dd>
                                 <dt class="page-number">Page:</dt>
                                 <dd id="page-number">2475</dd>
                              </dl>

Publication date, issue number, and page number are pretty much the only details needed; the publication (The London Gazette) can be trivially inferred from the URL, and there are no author details to fill. These can be passed either to cite news / cite magazine, or there is a London Gazette template on en-wiki (which is an implementation of cite magazine).

Would adding support for London Gazette articles be technically possible?

FDMS4 (talkcontribs)
Sasuke Sarutobi (talkcontribs)

Thank you! I hadn't spotted that section when scanning through the page, so I'll give Citoid/Creating Zotero translators a go at the weekend and see if I can set up a translator for it.

Summary by Gryllida

Mvolz clarified why older versions of node or translation-server were used for installing citoid - for the tests to pass.

Gryllida (talkcontribs)

The install instructions are confusing. There is

"sudo apt-get install nodejs npm

nodejs --version # should now print v0.10.x Note: not on Ubuntu Server 12.04 LTS, you end up with v0.6.x" at [[Citoid#Installation]]. On my Debian I get v4.8.4 ...

I would be ok with this, maybe it works but then I read the next part which says "Checkout the older version: cd translation-server git checkout 8d6eae22"

Is this relevant today?

Mvolz (WMF) (talkcontribs)

Nodejs --version - yes, definitely outdated, I'll fix that.

As for translation-server, unfortunately, yes that is the equivalent to what we're running in production. For most purposes though, you can just use the most recent version. (It's just that the citoid tests are run with this older version, so you might get some failing tests so if you're trying to run them.) You can use the official translation-server installation directions from Zotero otherwise: https://github.com/zotero/translation-server

Gryllida (talkcontribs)

Thanks that's great.

Boghog (talkcontribs)

Hi. I posted this 9 months ago under Bugs: pmc, redundant urls, and ref tags. The only topic that was discussed when I posted this previously was the pmc accession number prefix (issue #1) and Redundant URLs (isssue #2) got lost in the discussion. Therefore I would like to raise the second undiscussed issue again, this time with more background.

Redundant url parameters are often added when there is another more appropriate and compact parameter that produces exactly the same link. Examples include:

IMHO, Citoid should check the url, and if it matches any of the above patterns, then the more specialized parameter should be populated and the url parameter should be left blank. As it stands now, Citoid is adding both the specialized parameter and the redundant url parameter.

PerfektesChaos (talkcontribs)

Basically you are right.

The German template for printed material w:de:Template:Literatur does support DOI= as well as PMID= and PMC=.

Furthermore, German templates detect URL as above and will issue error messages and urge to use plain ID rather than URL.

Note that dx.doi.org recently changed to doi.org in new usages.

Whatamidoing (WMF) (talkcontribs)

I understand that most readers don't know that the clicking the PMID/doi/etc. numbers will take them to a useful page, but they do understand that clicking an article title that looks like an external link is going to take them to the article. From the POV of a non-technical reader, having the "redundant" link is very helpful.

Boghog (talkcontribs)

I think you are underestimating the intelligence and curiosity of the average reader. Readers understand that blue text contains a hyperlink and links generally lead to useful information. At the very least, if a reader is interested in a source and sees a link in the source, they are liable to clinic on it to see where it leads.

Furthermore the pmc parameter will also link the article title. Therefore |url=https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5615317/ is completely redundant with |pmc=5615317.

Reply to "Redundant URLs"

JSTOR is sometimes a journal and sometimes a website

2
AManWithNoPlan (talkcontribs)
AManWithNoPlan (talkcontribs)

More information. Once citoid goes bad, it stays bad for a while, and then suddenly works again. I have tried coming in from other IP address ranges and with other jstor IDs just to make sure that I was not personally being blocked. Thoughts: jstor some how blocks you, but you still get title with “ - on JSTOR” appended. There are multiple and different citoid severs running, but then I would think it would be more random and not last for a time period.

Reply to "JSTOR is sometimes a journal and sometimes a website"

404 URL returns data anyway that is wierd

4
AManWithNoPlan (talkcontribs)

When I submit this URL,

https://www.thecaterer.com/business/companies/33812/barracuda-group-limited

Citoid acts like it is real, even though it know that is is 404, and sends this back

[

 {
   "url": "https://www.thecaterer.com/business/companies/33812/barracuda-group-limited",
   "itemType": "webpage",
   "websiteTitle": "{{metaTags.other['og:site_name']}}",
   "title": "{{metaTags.other['og:title']}}",
   "abstractNote": "{{metaTags.other['og:description']}}",
   "accessDate": "2017-11-20",
   "author": [
     [
       "",
       "Template:MetaTags.other.author"
     ]
   ],
   "source": [
     "citoid"
   ]
 }

]

Mvolz (WMF) (talkcontribs)

Thanks for reporting!

Unfortunately this seems to be a problem with the website. Whilst the website *says* it's a 404, it's not actually a real 404 page. The http response header it claims it's a 200 ok response :D. The weird metadata is also because they're using a templating system that returns the raw template tags in the metadata of the page.

Unfortunately I'm not sure how actionable this is on our end- perhaps the best thing to do is to report the issue to the webmaster of the website.

Jonesey95 (talkcontribs)

Citoid should reject any proposed citation data with double curly braces in it. It causes error messages.

Mvolz (WMF) (talkcontribs)
Reply to "404 URL returns data anyway that is wierd"

Bad JavaScript Error "OO.ui.TabPanelLayout is not a constructor"

3
Janiko (talkcontribs)

Hi all, hope this is the good place to get some help. I'm trying to install Citoid extension on a personal wiki, with VisualEditor, and I get a bad JS error.

I have first installed mediawiki (1.29), enabled only a couple of extensions (Cite, Scribunto, TemplateData...), and Visual Editor. All works fine as expected. Besides, I have a parsoid+citoid (+ zotero/translation-server) server, working well too. I followed the setup instructions (here, here, etc.).

When I enable Citoid extension, I get no mediawiki error (in debug mode). But when I try to use the “Source” function, I get 2 JS errors I don’t get without Citoid (the “Source” function in VE works well with Citoid not enabled).

I tried on different browsers, with different skins, the result remains the same.

What I can see in the browser’s console is below. The 1st error make me think the oojs-ui is not well loaded though it’s installed (with composer).

Where to look to search the cause?

Thanks !

Janiko

(1) Uncaught TypeError: OO.ui.TabPanelLayout is not a constructor

   at VeUiCiteFromIdInspector.ve.ui.CiteFromIdInspector.initialize (load.php?...)

   at VeUiCiteFromIdInspector.OO.ui.Window.setManager

Code:        this.modePanels = {

           auto: new OO.ui.TabPanelLayout('auto',{

               label: ve.msg('citoid-citefromiddialog-mode-auto')...

(2) Uncaught TypeError: Cannot read property 'setDisabled' of undefined

   at VeUiCiteFromIdInspector.<anonymous>

Code:    ve.ui.CiteFromIdInspector.prototype.getSetupProcess = function(data) {

       return ve.ui.CiteFromIdInspector.super.prototype.getSetupProcess.call(this, data).next(function() {

           var fragment;

           this.lookupPromise = null;

           this.staging = !1;

           this.results = [];

           this.lookupButton.setDisabled(true);

           this.inDialog = data.inDialog || '';

           this.replaceNode = data.replace &&...

Mvolz (WMF) (talkcontribs)

To me this sounds most likely to be a version mismatch. Branches get cut for mediawiki weekly and you'll need to have the same branch for VisualEditor an Citoid, and OOUI/OOJS as they won't be compatible with other branches (although composer should be giving you the correct version of ooui :/). I seem to remember tab layout getting changed little ways back.

Where are you getting your versions? From git, or packaged somewhere?

The best place to ask for help would probably be somewhere there are VisualEditor devs, #mediawiki-visualeditor on IRC maybe? https://www.mediawiki.org/wiki/VisualEditor/Setup Or you might actually have more luck with people experienced in dealing with versioning issues i.e. #wikimedia-tech

If all else fails you can report a bug, https://phabricator.wikimedia.org/ and tag with VisualEditor/citoid.

Janiko (talkcontribs)

Thank you for your answer. Unfortunately I've reinstalled VE and Citoid, checked the branch label (both VE and Citoid with -b REL1_29 option while git cloning), relaunched git submodule update --init in VE directory and still got the same behaviour: VE works well until I try to load Citoid. I will try on phabricator.

Reply to "Bad JavaScript Error "OO.ui.TabPanelLayout is not a constructor""

Publication date field for some scientific journals are not provided anymore

5
Summary by Whatamidoing (WMF)
Albert Ke (talkcontribs)

Hi,

It looks like for certain scientific journals the 'publication date' field isn't provided anymore. For example for the "Earth Surface Dynamics" journal you will see the publication date (See e.g.: https://en.wikipedia.org/api/rest_v1/data/citation/zotero/10.5194%2Fesurf-5-21-2017 which has the publication date provided as: "date":"2017-01-16").

However, the "Geology" journal, published by "geoscienceworld", has no publication date through zotero (See e.g.: https://en.wikipedia.org/api/rest_v1/data/citation/zotero/10.1130%2Fg38665.1 (only access date is shown)).

Would there be a quick fix such that publication date can be pulled through zotero as well?

Thanks, Albert.

Whatamidoing (WMF) (talkcontribs)

I don't know how to check for this myself, but usually, when something like this happens, it means that the 'broken' sources have rearranged their websites, and that the Zotero translator needs to be updated as a result.

Albert Ke (talkcontribs)
Whatamidoing (WMF) (talkcontribs)

I don't know how to edit the Zotero translators. However, @Czar and @Mvolz do.

Czar (talkcontribs)
Reply to "Publication date field for some scientific journals are not provided anymore"
ערן (talkcontribs)

Is scribunto really needed for working with citoid? If not, consider to remove it from the documentation here

Reply to "scribunto"