I’ve been running into some difficulties recently with the way OJS displays multilingual forms and I think there could be a way to curate it. I haven’t found any post dealing with it, so I create a new topic here.
Currently, for journals that publish in multiple languages, locales of every language used must be installed and activated for both submissions and forms (which are linked by virtue of Merge pull request #3486 from bozana/3302 · pkp/pkp-lib@1fec084 · GitHub).This means that for each field, there will be as many text boxes as there are locales installed.
The “problem” is that not all of these locales are necessarily UI ones. Indeed, many multilingual journals may use only one or two UI locales, yet publish in many more languages, either because the UI locale is a vehicular language (typically English) or because publication in a language is too rare to maintain a full-blown UI locale for it.
The thing is, I don’t understand the purpose for displaying fields for locales that are not UI unless the submission is specifically made in that language. Not only are those fields almost never filled out when the submission is not in that language, but even when they are, they serve no purpose for the editorial process and will never be seen by the viewer. So essentially we end up with a series of fields that are useless, confusing for the author and that affect the display.
A fix would be to always display language fields that are UI, but to only display non-UI locales when that language is selected for submission.
Tell me if that makes sense or if there is something I’m not seeing here,
Thank you for your reply! If I do that, I have a multilingual UI (French and English in your example) but only one submission language (English here). My point is to have it the other way around, i.e. to be able to only have, let’s say, English as UI language, but to be able to submit articles in French. The only way to do that currently is to check Forms/Sub. for all languages. The problem of that solution is that every form on OJS will then become bilingual. In our example, it means that if I want to submit an article in English, a French field will also be displayed, which is useless since French is not UI.
One can live with that for 2 languages, but it becomes completely insane if a journal has one UI but accepts submissions in 3 or 4 locales, which is not a far-fetched idea (e.g. a European-wide journal, a linguistic journal or a journal in a country that has multiple official languages). In that case, regardless of the submission language, forms will appear in all the other languages, even though the only required ones are the submission language and the UI. Visually, the display becomes quite messy and frankly confusing for the user.
I agree with this. We have a journal that accepts several Nordic languages, but only has English and Swedish as UI languages. They used to have forms only for Danish and Norwegian, but I had to reset their language settings, which I believe triggered this fix. They now have to fill out two extra forms all the time, for instance when they are creating announcements. Doesn’t make sense to the user.
Is there a workaround that we can use? If not, I think this would be a good solution:
@rcgillis we are on 3.3.0-6. My apologies, I was incorrect. The part about them having to fill out every language field seems to be due to a bug with this particular journal, we are looking into it. What @pheckler described is still a relevant comment imo, the backend gets messy and confusing for journals that have these specifications. Sorry about the confusion!
Can you describe the problem you’re facing and the precise language configuration you’re using (maybe a screenshot?). Fields for languages should only show up in forms if the corresponding language configuration has the language enabled:
UI: no extra fields appear in the forms. It only provides automated translation of stock language entries (eg - the Archives/Current links in the navigation menu)
Forms: extra fields appear in forms for most settings (about the journal, sections, issues, etc) as well as some public items (announcements, etc)
Submissions: extra fields appear in the forms under the Publication tab (title, abstract, etc)