Languages configuration suggestions

Feature Requests
, ,
1

I would appreciate suggestion on the following issue:

Our journals publish article galleys in more than 10 languages, while each article basic metadata (title, abstract) are published in two languages. OJS interface should offer two languages too (the same as for articles metadata).

Is there a way to set up OJS the way that it offers more languages for galleys only, without being required to also provide metadata for each article in those additional languages?

In OJS 2 to accomplish this flexibility we had to use only single language for interface/locale/forms, and for galleys we used labels to describe each galley’s language (while technically each galley had English language assigned) and provided translations of portions of the interface on the same page without switching languages functionality.

I was wondering how this has changed in the most recent OJS versions. I did a few tests so far and I noticed that I am able to add more languages and only assign them to submission but at the same time I have to provide metadata in those additional languages too, and I only need those extra languages for galleys. Am I missing something obvious within OJS configuration or this approach is still not possible?

2

Hi @piotreba,

Interesting question. At present, OJS offers locale configuration for the main UI, submissions, and forms:

https://docs.pkp.sfu.ca/learning-ojs/en/settings-website#languages (this is for 3.3).

I think that the metadata configuration would likely fall under “Submissions” (but I’m not 100% on this), but I don’t think that allows one to get more specific with galleys. I think the expectation is that if a galley is being provided in a particular language, that it should be accompanied by metadata in that same language - but perhaps you have a different approach/rationale?

I will note, however, there is this open issue here: Improve galleyLabels for multilang journals · Issue #6275 · pkp/pkp-lib · GitHub

it is geared toward improving multilanguage galley labels - but not quite in the manner you’re describing. I have however flagged this in the “Feature Requests” category, which our developers monitor and can comment further on this.

Best regards,

Roger
PKP Team

3

@rcgillis,

Let’s say our journals accept manuscripts and publish in languages A, B, …, K. UI is in language A and B. We so far have been used to publishing works the way that metadata are in language A and B, but full text could be in other language, e.g., J.

I am now further testing submission process in OJS 3.3. I set up four languages, A, B, C, D, the following way:

A: Primary locale, UI, Forms, Submissions
B: UI, Forms, Submissions
C: Forms, Submissions
D: Forms, Submissions

First, I cannot select a language just for submissions; the “forms” checkbox selects automatically too.

Second, say I am submitting a manuscript in language D. I can select it during submission’s Start step. BUT, Metadata tab’s fields, such as title or abstract, present me fields for ALL the languages installed for the journal website (although only the main manuscript language selected in the Start step being required as far as I’m aware), while I would expect that only selected languages for metadata (and galleys), e.g., original manuscript language, and those of UI (because these would be so called internationally recognized languages, which is not always the case for the full text language), to be presented for an author and required during submission.

If the journal accepts manuscripts in, e.g., 5 or more languages (which is the case for our journals, oftentimes dealing with linguistics), this can be problematic and misleading. This variety of languages should be offered for authors selection.

OJS 2 has Language field on the metadata page, although I’m not sure how this translates to metadata exported to external services.

4

Hi @piotreba,

Thank you for your further explanation:

  • I see what you mean. This happened to me too when I tried to test this. @NateWr - do you know why this is the case?

Second , say I am submitting a manuscript in language D. I can select it during submission’s Start step. BUT, Metadata tab’s fields, such as title or abstract, present me fields for ALL the languages installed for the journal website (although only the main manuscript language selected in the Start step being required as far as I’m aware), while I would expect that only selected languages for metadata (and galleys), e.g., original manuscript language, and those of UI (because these would be so called internationally recognized languages, which is not always the case for the full text language), to be presented for an author and required during submission.

In particular, it’s noted by NateWr (further down on the thread):

Just a note that we may or may not be able to prioritize a fix for 3.3.0-x. But this problem should be avoided in 3.4, because we are rebuilding the submission wizard and it will use the new system for multilingual forms. See #7191

@NateWr will hopefully be able to speak further to this when he is available.

-Roger
PKP Team

1 Like
5

@rcgillis, great this issue has been recognized and is planned to be addressed. Languages configuration in OJS definitely needs more flexibility on different editorial and administration levels. UI language(s) may have nothing to do with the language(s) of an article metadata and/or galley(s).

1 Like
6

I am still discussing the issue among editorial team while trying to find the optimal way to set up languages for journals publishing articles in more languages than those defined for OJS UI. It seems that for now (tests on OJS 3.3.0.10) the best way is to leave a single (e.g. English) language for the Forms and Submissions language setup (we were following this approach in OJS 2). But this on the other hand:

  1. incorrectly translates into some metadata: formally they are described by (following the example) “English” language attribute, and
  2. with (at least) double-language OJS’s UI, the galleys are labelled as, e.g., “PDF (English)”, even though the language of the work is different (but there is no way to define galley’s language separately from the Forms and Submissions language setup, right?).

There is one option that might be handy for denoting the original language of the work (it was also present in OJS 2):

Workflow Settings > Submission > Metadata > Languages

but actually what’s the purpose of this setting? I couldn’t find it in metadata of either DOI or DOAJ as well as in the source code of an article’s landing page.

The user experience in terms of dealing with languages for journals accepting/publishing articles within the languages of the UI seems pretty straightforward, but otherwise I find it very confusing (sorry if I am missing something that might solve the issue!).

7

If I can put in my two cents again, I’d see dealing with languages the following way, generally:

  1. Journal managers should be able to set up complete list of languages available for submissions in a journal (this is currently available here: Website Settings > Setup > Languages); from this list, authors select the primary language of their manuscript during submission.
  2. Journal managers should also be able to define a list of languages in which the article metadata are to be collected; however, the options should include something like “primary language of the manuscript” which should reflect the language of the manuscript selected by the author during submission; apart from this option there could be other predefined languages available for selection in which the article metadata could be collected. The fields for the primary language of the manuscript’s metadata should be displayed as first in the forms related to metadata, with additional languages below (if different from the primary language of the manuscript). Metadata in the primary language are always required, while additional metadata languages could be optional (if the journal cares, the editors could enter everything which is formally required themselves before publication; authors may be unable to enter some metadata in languages they may not be familiar with).
  3. On the front-end, I think there should always be displayed metadata (title, abstract, keywords, etc.?) in the primary language, regardless of the selected UI language (TOC, article landing page). This is important from the bibliographic perspective to know what the original language of the work is (e.g., to cite it correctly; the “How to cite” plugin takes the translation, not the original title). Currently, this information seems only to be discoverable from the galley button (the system adds a language note to the galley label, but only if the UI is different from the galley language). If there are also metadata available in the language of the selected UI, and if they are different from the primary language of the work, they could be displayed below the primary language metadata (e.g., in a smaller type).

Apart from that, some forms require providing, e.g., file names in all languages selected for a journal (imagine this in a journal with 10 or more languages, the case I am currently trying to deal with), so it would be handier to also make forms languages more independent from the UI/submission metadata languages.

Thanks, hopefully I didn’t miss anything obvious in my current tests that’d actually be in line of the above approaches.

1 Like
10

Multilingualism and metadata extensibility is a work package of the Craft-OA project (see deliverables list here https://www.craft-oa.eu/results/deliverables/) where many members of the PKP developer community are engaged. There should be improvements to come in the next few years.