How in OJS 3.1.2.0 in a standard theme to make input of literature for each language?

Software Support
1

Hello. Help to understand. Installed OJS 3.1.2.0, the theme is standard (included). The magazine’s website is bilingual. The question arose in the placement of the article and found the problem - the reference list is not populated for different languages, but one single window, as a result it is the same for each language version of the site, which is unacceptable, as foreigners don’t need to see Russian language, and Russian on the contrary, English. Tell me, maybe someone has already faced this question, how to solve this issue? Is it possible to change the theme files or the OJS itself so that there is literature input for each language? help to understand where and what to change, so as not to spoil the working site. Thanks!

2 Likes
2

Hi, Yuri!
Look at Обновление Open Journal System 3.1.2 - О жизни, информационных технологиях и всём остальном.

1 Like
3

Hi @litvinovg, @asmecher,

This might be really important for many of us. Would it be possible to add those PRs to the master?

4

Thanks for the answer. Looked materials on exiled, but, frankly, not quite understood, that and where to change in incumbent stable OJS 3.1.2.0 for moreover, to zapuyennyy and filled site not stopped work. I will be very grateful for the explanation.

5

Installed as plugins through repacking in tar.gz all on data references… nothing has changed either externally or in the administration of the articles in the issue. I wrote another email to the developer, maybe tell me what I did wrong or did not understand…
image
I need this field to become multilingual, like everything on the previous tabs.

6

Hi @Yuriy_Kadatski,

Making the list multilingual opens the door to a lot of potential problems – if you’re able to paste a different list for each language, we have no guarantee that the lists will be the same length or that e.g. the third reference on the English list refers to the same item as the third reference on the Ukrainian list. However, I have asked our metadata working group for recommendations and we will see what they say.

Regards,
Alec Smecher
Public Knowledge Project Team

7

Let me disagree with the judgment that only one language and one list of literature is important. Yes, this is purely technically important for international databases, their systems for accounting for articles, citations and other things, but you forget that this, the only list of references arises from many foreign works, and that is important, these scientific works have their own language groups.
Example. I am writing an article in Russian, in co-authors I have Ukrainians, Poles. The main language is Russian, for they all understand it + the journal where the article is printed is located in that country, although this is all conditionally finite. Each of the co-authors, when writing an article, relies primarily on their own works or national ones, and this is correct. As a result, the first, main list of references will be very multilingual.
Further, in order for the article to be correctly quoted, it is translated into English, and all literature is transliterated. As a result, we have such a correct hybrid article, when they did something nice for their own and pleased international databases.
But it’s all only in the magazine’s market itself, that electronic, that printed. If you start loading this hybrid article into OJS, then you come across the fact that only English-language or transliterated material is important in many respects, because in many places there is no possibility of dividing its relevant parts into languages.
Based on the described example, it seems to me, in my not yet experienced, that OJS more respects the rights of international databases, but not the development and citation of the same materials in national databases. It is just sadness that leads to the creation of such topics.
OJS is a very cool platform and I would really like it to be truly multilingual, with all the positive aspects listed above.
Thank you for your understanding.

3 Likes
8

Hi @asmecher,

AFAIK, there are no databases, which may support uploading different lists for each language. Thus, I suspect there is no need to require those lists to be the same length.
So I’d support making this field multilingual.

What is important: 1) All metadata exported should be in the same language (already filed here: [OJS 3.1.2-1] Crossref module: Language of all metadata EXCEPT author names depends on submission language (author names depend on locale chosen) · Issue #5061 · pkp/pkp-lib · GitHub), 2) This language should not depend neither on the locale chosen at the moment of export, nor on the submission language. IMHO, it should be chosen explicitly by the journal manager.

1 Like
9

Hi @asmecher

Maybe it will not matter if all citations are extracted and has DOI. The numbered list is no longer displayed, and the sequence of bibliographic items is no longer so important. Anyway it may be just… like a difference between English and Ukrainian abstracts or keywords and nothing more. And the language of the extracted metadata-references may depend on the specified language of the article (how abstract-metadata is exported now with the help of the Crossref export plugin, for example).

10

If we take Google Scholar, then again, it would always index only some one page per article. So it would not index several lists of references, trying to ‘see’ any correspondence between them. AFAIR.

12

Hi all,

Thanks for all the feedback – I’m continuing to talk with our metadata group about this. Here are some references I’m looking at:

The last document is the most relevant for me, as we often look to JATS as a template for how to better manage metadata. Publishing with OJS is increasingly tied to being able to create/manage good JATS XML.

On references and citations, Introduction to Multi-language Documents in NISO JATS has this to say:

Multiple Single-language Reference Lists

In other multi-language documents, the entire Reference List may be provided in two or more languages. This also requires no special structures or handling in NISO JATS: the Reference List element is allowed to repeat, and each Reference List takes an xml:lang attribute. Some publishers prohibit this practice because they fear it could artificially double the number of citations.

There’s a lot more useful/interesting data in the document, but suffice it to say that JATS can handle both fully-repeated-in-each-language lists, and multiple-languages-specified-within-each-bibliography-entry lists.

I’ll double-check this with the metadata group, but based on that, I’m content to make the bibliography field multilingual-capable – with the caveat that I think this is a one-way street, i.e. if we discover later that we need to be able to match the Spanish and Ukrainian materials to the same common entity, we’ll be in trouble.

Regards,
Alec Smecher
Public Knowledge Project Team

3 Likes
13

Hi all,

This is filed as a feature request here: Make reference list multilingual-capable · Issue #5303 · pkp/pkp-lib · GitHub

Since I believe some of you have customized OJS to support this, a pull request would be welcome!

Thanks,
Alec Smecher
Public Knowledge Project Team

3 Likes
14

@asmecher, thanks for your great contribution. I do agree that we should take into account any possible use cases of such ‘parallel’ lists.

As to the APA Style Guide, it should not be a ‘big threat’, since it only requires translating into English all non-English titles (and Latinize them in case of non-Latin characters). And it is not ‘backwards compatible’, since it would not require translating any English title into other languages. Some other (national) styles may not require any translation whatsoever.

So multi-language journals might use different styles for lists in different languages. E.g. some national style for articles in their native language and APA for any other. Which might make the task of linking items in those lists even harder.

Indeed, we cannot guarantee any such linking by only requiring those lists to be of equal length. Since they might be sorted differently based on different alphabets.

As to JATS XML, I can conceive those fully-repeated-in-each-language lists. However, I cannot conceive how the end user might benefit from them. Tagging @vitaliy, since he might have had some experience with such entities. Whatever they might be, I think several lists should not co-exist on the same page, since they would be indexed incorrectly (by GS).

1 Like
15

Thanks for your understanding and upcoming developments! I will be happy to support the project due to my knowledge and capabilities.

16

Hi @Ph_We/all,

As to JATS XML, I can conceive those fully-repeated-in-each-language lists. However, I cannot conceive how the end user might benefit from them. Tagging @vitaliy, since he might have had some experience with such entities. Whatever they might be, I think several lists should not co-exist on the same page, since they would be indexed incorrectly (by GS).

Yes, indexing is a risk identified in the JATS document (and in fact it states that some publishers prohibit the practice for this reason). However, I think it’s important to provide all possible information downstream within the constraints of the data standard, and JATS does explicitly support the multiple-lists data model. It’s up to the downstream entity to ensure that the presentation doesn’t make assumptions about the content that would lead to e.g. indexing problems.

As for a use case, you can imagine a case where OJS is used for workflow but not publication, and an external front-end is fed with JATS XML to populate the front end. That interface could offer a language toggle, just as OJS does, and the resulting HTML would include the reference list in the specified language.

Thanks,
Alec Smecher
Public Knowledge Project Team

17

I don’t have experience with multilang reference lists but I’m helping to manage the journal, which exposes articles fulltext from JATS on article landing page in 2 languages. The language version of JATS that is shown to the user depends on a chosen locale with a drawback to the available one if fulltext is not available for a specific locale. To avoid confusion, I’m keeping a separate JATS XML file for each locale, although I’m not sure if it’s a right approach.

This is the case for our journal as we have several lang versions of the article on the landing page but we applied a solution. To ensure that the text is indexed by Google 2 languages, each OJS locale has a unique subdomain - that’s how we adopted unique URLs for multilingual content, see: Managing Multi-Regional and Multilingual Sites | Google Search Central  |  Documentation  |  Google for Developers
Google Scholar is indexing the article in different languages as the same one. So, theoretically, the same could be extrapolated to the references too, at least when we are talking about Google Scholar.

1 Like
18

Yes. The reference (Bibliography) is possible only in one language. The best way is to paste whole list in English.