[Forms] Improve multilingual behaviour of old&current forms

[jardakotesovec]

Hoping these changes could address pain points from these issues:
#6291
#5136

Legacy forms

Make required field always being first input

Problem

Lets assume we have english & french locales enabled, where English is set as Primary&Default for given context

If I change my UI locale to French in the user dropdown, suddenly legacy forms prioritise French to be first input to show. Due current implementation - both english&french are required to be entered. Just because user changed how they want to see the User Interface.

• both english and french are required, french is displayed first because UI interface is set to french
• first language placeholder is not displayed

Proposed solution

• Follow current forms behaviour - where always the primary is first, because thats the one which is required (when field is required).
• To make clear which language is first one - show 'language' placeholder also for the first input, not just for the other one.

• first language is english, because thats primary language (required one), french is optional
• language is displayed in first input so its clear which language is expected
• more inline with current forms, which does consider currently selected Locale only to additionally display it (on non-submission specific forms), but not make it first&required.

Current forms

Required fields indication

Problem

Currently we show pink asterisk for all language, despite actually requiring just primary locale.

Solution

Don't display asterisk for languages that are not required, so it would be displayed only for primary

Order of locales - sometime required is not first, confusing UI

Problem

We don't consistently order the locales to ensure that the primary language is first. That sometimes results in following rendering

Solution

Always sort locales to ensure that the primary is the most left with actual field names.

User specific forms

Problem

Given that user is in the system just once and than its associated with individual journals - there was always rule to enforce having the first name in Site Locale. Which with current implementation results in requesting names in multiple languages if its different from context primary language.

Solution (not included in this ticket, see update below)

On the server side - if the user details are saved and the site locale is empty - just copy over it from the context primary language.
From UX point of view - people expect to follow the Context (Journal) setting. Therefore its good to have site locale there to be among the options that can be edited, but better not to require it to enter directly from user.

Therefore user related forms should be configured in same way as other context specific forms, with site locale just to be added on the list of locales that can be edited there.

Update: after some internal discussions with Devika, will exclude automatic copy over, as we need more detailed research to make sure it does not cause issues for certain scenarios.

That should make the UX smooth - as most users (including editors) will expect to deal with context locale setting, than site locale setting. And copying over to site locale setting on updates (if empty) will ensure we have always something to show - even in cases when two journals might have different language configured.

PRs
ojs: pkp/ojs#5481
ui-library: https://github.com/pkp/ui-library/pull/866/changes
pkp-lib: #12545

[ajnyga]

Thanks. My issue was about the last point you raised here. I think the same solution - copying the user data from the context locale to the site locale - was discussed there as well. I am not 100% sure it is a good solution but could be the only viable one.

The problem was especially situations where the site primary locale is not used at all in the context. In these cases the copying should happen in the background.

[alexxxmendonca]

I really like the proposed changes. Hopefully they will improve usability and decrease errors and frustrations.

Regarding user first and last name -- I am not sure if you are touching on that matter on your last comment, but do we really need these fields to be translated? There had been cases where the author has multiple surnames and add them differently in each language, resulting in their names appearing differently depending on the UI language that is chosen.

For instance, an author called "José Maria da Silva" may type "José" as first name and "Maria da Silva" as surname on one language and "José" as first name and "Silva" as surname in another language.

The result is: one UI will show "José Maria da Silva" while the other will only show "José Silva".

I don't think names should have translated fields -- or at least, by default they should be copied over and let the user decide if they want to change the translation or not.

[jardakotesovec]

@alexxxmendonca Thanks for feedback!

Typical use case for multilingual names where it make sense was mentioned here - #5136 (comment)

But I understand that for most journals its unnecessary. Hoping that these adjustments which basically avoid forcing user to enter it multiple times and its copied over if needed will improve it. Downside is I think just that some people might think they need to enter it twice, or if they would edit it later - they would need to edit the additional locale. Will keep it in mind. Once are modernising these areas whether we could improve it further.