[OJS 3.3] Form requires system primary locale fields for journals that only use secondary languages

There are multiple languages enabled sitewide, with Spanish as Primary locale (Administration > Site settings > Languages)

Using a journal that only have English enabled, some forms require multi-language fields with both English and the sitewide primary language. Example forms: adding a user, adding a reviewer.

For this journal website settings > setup > languages, English is the only enabled language (Primary locale, UI, Forms and Submissions are checked)

I couldn’t find a way to avoid the requirement for the primary language sitewide that is not being used in the context of this journal.

Is it possible to do it or is it the expected behavior for the new and more robust multi-language support?

We’re running a recently updated OJS

Thanks in advance!

I didn’t quite understand what you mean. Can you show me the “Language Settings” page so I can say something exactly?


Hi Kerim,

thank you for answering and I’m sorry if wasn’t clear enough!

This is a multijournal instance, and the system language settings are these (Español/Spanish is the primary local):

Screenshot 2021-08-23 at 19-50-54 Site Settings Portal de revistas de la UNS

There’s a journal with these languague settings (English is the only enabled language):

Screenshot 2021-08-23 at 19-52-10 Website Settings Revista de la Unión Matemática Argentina

But some forms within this journal require require both English and the sitewide primary locale (Español/Spanish), for instance adding a user:


I think that if you make the site language (primary locale) English, the problem will disappear.
Because the language of the site (Espanol) and the language of the your journal (Ensglish) are different. Therefore, even if you choose one language, 2 languages appear. So, site settings (site setup) are more important than website settings.

I think that if you make the site language (primary locale) English, the problem will disappear.

Yes, sure, that’s the logic underneath. But I wonder if its possible to use single language forms for journals that do not use the system primary locale.

1 Like

Maybe @NateWr or someone else working with the frontend?

Any hint is appreciated!

Hi @gonzalognzl, this is an uncomfortable UX that arises from the old form design and the user language fallback. In short, the user should not have to enter any information into the Spanish field there, but the UI requires it if the user’s focus enters the field. This is fixed with the new form design but we haven’t yet rolled this out to the create user or create reviewer forms.

You can see a previous discussion in this thread and a feature request to fix this is filed in this GitHub issue.

Nate, the discussion you link the thread becomes a little blur about the real problem… that IMO is a ui/uix issue that could be temporarily addressed if we replicate the same content in each field.

Was not my intention to double post, but this year I posted again about this and I feel the explanation of the problem (and the potential workaround) becomes a little more clear here:

Adding both links to the gitHub thread to keep stuff sorted.

Thanks a lot for your work Nate.

Thanks @NateWr and @marc,
I didn’t find any related post to this issue and that’s why I’ve created a new one. Now I see it’s been a topic for a while. Sorry for that.

Anyways, following what @NateWr says (and also @marc here for 3.1.2)

the UI requires it if the user’s focus enters the field.

I see that the UI requires these fields even if the user’s focus doesn’t enters the field. So I don’t find any workaround except filling in both fields.

Hi @marc , @NateWr

Reporting back just to share a simple solution following Marc’s idea: with name related fields, I just don’t show the multi-language popover and then replicate the first value for every other language in a hidden way. It’s managed in the frontend, so in users_settings table all fields are saved with multi-language support.

If anyone is interested, after modifying lib/pkp/controllers/forms/MultilingualInputHandler.js, pkp.min.js should be compiled again.

It’s a temporary solution that does the trick if the users will always be filling in the same value on every language occurrence, depending on your language settings and needs.

--- MultilingualInputHandler.js.orig    2021-09-28 13:07:16.355189393 -0300
+++ MultilingualInputHandler.js 2021-09-28 13:23:01.825157311 -0300
@@ -115,14 +115,14 @@
        $.pkp.controllers.form.MultilingualInputHandler.prototype.showPopover_ =
                        function() {
                var $popover = this.getHtmlElement();
-               $popover.addClass('localization_popover_container_focus');
+               //$popover.addClass('localization_popover_container_focus');

                // Hack alert: setting width in JS because they do not line up otherwise.
                                /** @type {number} */ ($popover.width()));

                // Show the pop over.
-               $popover.find('.localization_popover').show();
+               //$popover.find('.localization_popover').show();

@@ -181,9 +181,17 @@
                } else {
                        $inputs = $popover.find(':input');
                        $inputs.each(function() {
+                               if ($inputs.is(":input[id^='givenName']")){
+                                       $inputs.removeAttr("required");
+                                       $inputs.val($(this).val());
+                               } else if ($inputs.is(":input[id^='familyName']") || $inputs.is(":input[id^='preferredPublicName']")) {
+                                       $inputs.val($(this).val());
+                               }
                                if ($(this).val()) {
-                                       valuesCount++;
-                               }
+                                        valuesCount++;
+                                }
1 Like

Thanks a lot for sharing Gonzalo.

Your snippets “full disables” the multilang feature or only replicates the default lang when others are empty?

I’m wondering what would happen if a user likes to keep different names in different languages.


Yep, Marc. Applying this changes:

  • won’t let the user keep different names for different languages.
  • will replicate the first value to any other language enabled on the journal (and system primary local too even when it’s not enabled on the journal, at least for OJS 3.3)

So this will be useful for some language settings and needs only. My main intention was to avoid multilingual name fields for journals that don’t use the system primary local, which originated this topic.


Thanks for the explanation and the code. :smiling_face_with_three_hearts:

So your “remove multilang ui/ux in users names” snippet will be helpful in a lot of scenarios, but it won’t be an option for journals that like to keep this multilang feature with a less intrusive ui/ux.

I mean, I really appreciate your work but, thinking in a definitive solution I want to make it clear that an “enable multilang fields” action when writing the name (click on the globe icon or something) would be a better solution… so we can store same data for all langs, except if user is explicitly asking to keep it different (ie: A journal with 99% latin langs users, but exceptionally a 1% with Chinese or Cyrillic).


1 Like

Yes! Completely agree :+1:

1 Like