pkp-lib icon indicating copy to clipboard operation
pkp-lib copied to clipboard

Make reference list multilingual-capable

Open asmecher opened this issue 6 years ago • 6 comments

The submission's reference list field is currently not multilingual.

In cases where publishing happens in multiple character sets (e.g. Cyrillic and Latin), having a list for each language is a frequently-requested option.

See https://forum.pkp.sfu.ca/t/how-in-ojs-3-1-2-0-in-a-standard-theme-to-make-input-of-literature-for-each-language/57124/12 for discussion, including a link to the JATS orthodoxy on the subject.

asmecher avatar Nov 27 '19 17:11 asmecher

Does the platform currently not support bibliography with support for multiple languages?

ipoliarush avatar Apr 01 '20 10:04 ipoliarush

No, not at the moment. See the linked discussion for some of the issues involved.

asmecher avatar Apr 01 '20 17:04 asmecher

related discussion: https://github.com/pkp/pkp-lib/discussions/8207#discussioncomment-3468892

fgnievinski avatar Dec 22 '22 19:12 fgnievinski

I have started working on this. There may be two (or more) options how to do this using the forms:

  1. Add one reference (all languages; separate fields for different languages) at a time using an add button. Store primary language to 'citations' table and additional languages to 'citation_settings' table. 'citation_id' links additional languages to the primary. Needs more UI changes than option 2.

  2. Add references using a text box per language. Store all languages to 'citations' table. Add 'locale' field to 'citations' table. References are not linked between languages but UI stays pretty much the same.

jyhein avatar Mar 08 '23 05:03 jyhein

@bozana, I wanted to get your thoughts on this. My thoughts are...

  • Even if it's not important for data consumers now, we shouldn't permit mismatched reference lists to proliferate because they'll be hard to clean up later. So we shouldn't allow someone to paste e.g. a 21-reference list in English, and a 15-reference list in Spanish. (It is possible we could clean it up later by e.g. matching DOIs, but it smells like a headache with a lot of outliers.)
  • We probably should decide on a single way to store references. Currently we have both the whole-list field, and individual citations split by line. There are still some remnants of the old citation assistant, e.g. the citation_settings table.

asmecher avatar Apr 13 '23 17:04 asmecher

@asmecher, yes... let me think about it... I will come back here... EDIT: citation_settings is still used, e.g. for found DOIs by CrossrefReferenceLinkingPlugin. I assume -- but it is to maybe be double checked -- that different citation languages will have one and the same DOI and we will only provide citations in the submission primary locale to crossref, when depositing the article DOI. Thus, in order to display found citations DOIs also for other languages, there will need to be the link/connection between citation's different languages i.e. we would need to know e.g. this is a different language version of this specific citation (e.g. they all would have the same ID in the DB). That means that it would be best to be able to edit single citations and in different languages. But, adding every single citation separately would mean a lot of work for the editor, thus we might provide both: the text area as till now for editor to enter the whole list of citations -> we would extract the single citations and provide the text field for each, so that they could be edited. Here is then still to think about how the different languages should be entered/edited... And let me think about the possible data model... Also the saved whole-list was used to see if anything has changed when user edits the references and if thus references needs to be parsed again.

bozana avatar Apr 14 '23 09:04 bozana