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?
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.
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.
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 @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 @marchere 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.
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.
$popover.find('.localization_popover').width(
/** @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++;
+ }
});
}
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.
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).
