Configure "Author name conventions"

Feature Requests
,
1

Before going to github, I like to ask the community about this to be sure it’s not just us.

As you will probably noticed, in 3.1.2 new feature was added:

Community Priorities

OJS is used worldwide in multiple languages. Perhaps one of the most notable community priorities addressed in 3.1.2 relates to this international use. Author name conventions are now much improved to better support multilingual names and different name conventions. First and last name are no longer required fields, and authors can now clearly articulate their preferred public name.

Source: https://pkp.sfu.ca/2019/03/01/ojs-3-1-2-released/

We see this as a serious i18n effort and it makes us happy, but unfortunately, the final implementation is confusing for our users. Let me explain why:
Usually in Spain, we don’t translate names… I mean, your name can be as complex as “Ricardo José Clemente Mella Cea” where “Ricardo José Clemente” is your name and “Mella Cea” are the surnames (or family ones)… but you name is the same here and in the china republic. :slight_smile: They are never translated.

OJS 3.1.2 is working as follows:

imagen
imagen1625×709 26.6 KB

imagen
imagen800×456 17.2 KB

The point is, now, in every user profile and authors/contributor’s names, you are requested for your name and family name for every lang enabled and this is a mess for our users.

I suspect this will be really useful (for instance) in countries with non latin char-sets, but in other ones, this solution makes the form really confusing.

So the proposal here is: What about a setting in config.inc.php or in a OJS setting how do you want to deal with people’s names? At the end we only have 2 questions: What fields are mandatory and singleVSmultilang request.

Probably, it will make everybody happy. What do you think?

Thanks for your work,
m.

4 Likes
2

I don’t see much community feedback (probably because only a very few are using 3.1.2) but the petition seams logical and feasible and I promise you it will avoid lots of future complains.

@asmecher @bozana ¿any comments on this?
¿do you want me to open an issue in github?

3

@marc

I talked with @natewr and it seems this is an presentation issue of the form.

You can still save the form without entering any given name for the languages but the validation error is presented if you select the field of the secondary languages and leave them empty.

I filed an issue for this in the GitHub repository:

Regards,

Nils Stefan Weiher

1 Like
4

Thanks for the info @nweiher

Anyway, looks like I didn’t explain myself.
I’m not talking about an issue with the validation… the simple existence of multiple fields for the given name is the issue itself. My users reported it makes the interface very confusing because it’s a field they never expect to be asked for.

So I still defend it need to be a setting (never-mind if in the ui or in config.inc.php)

Cheers,
m.

5

Hi @marc, yes I agree that it’s unnecessarily confusing. Our new forms make multilingual fields less intrusive, so when this form gets updated to use that approach the multilingual input should not present as much of an issue.

A setting presents a greater maintenance burden for us in the long-run because it increases the configurations we must manage. And besides that I think that there is some risk of obscuring data (a user’s name may exist in the database and be shown in another language, but the user is unlikely to see this and can not change it if they do), so I’m hesitant to hide the data away completely.

If you want, you can create a plugin to overwrite the identityForm.tpl template and hook into IdentityForm.inc.php to make these changes. Of course, then the maintenance burden is on you, not us. :wink:

1 Like
6

Hi Nate,

I don’t remember if I told you before, but I’m a big fan of your work. :wink:
I know you are not alone in this battle but it’s fair to say that OxS tools UI/UX improved a lot since your arrival. So thanks.

Certainly, the new approach is less confusing and I like a lot… but I can’t avoid keep thinking that we are asking for fields that in latin languages will be empty in the 95% of the cases.

I understand your comments about the database-frontend fields match, but a field is asking you to write something so in most of the cases they will duplicate info, even with typo errors, so this is even worse than keeping the field empty, don’t you think?

The plugin is a good suggestion, but unfortunately I won’t be able to work on this, at least, till the next year. :frowning:

Let’s see if somebody else has time and interest to take the responsible . :wink:

Cheers,
m.

7

Marc, mientras no pulses el campo de otro idioma, no te lo “requerirá”. Por ejemplo, si tabulas, y “toca” el campo formulario en catalán, por ejemplo, te lo requerirá como obligatorio… la solución temporal es rellenar en el idioma principal y clickear fuera con el ratón. Una pequeña chapuza pero puede servir mientras dan con el error

Don’t click or tab into different language fields, just click out and they will not be required

8

Si, si… ya lo pillé, pero por lo que veo la elección del idioma no es por campo, sinó para todo el formulario.
Es buena idea tener un campo BIO multilang, pero si lo relleno, también me pedirá que traduzca los apellidos… y con algunos autores/revisores/usuarios les va a generar dudas.

Alex ¿te parece bien volvemos al inglés y así todo el mundo puede aportar?

Translation :slight_smile:

Yes, yes … I’ve already caught it (fields only appear if you click on a different lang), but the lang election is not by field, if by form.
I mean, it’s a good idea to have a multilang BIO field, but if you fill it out, OJS will ask me for my family name… and with some authors / reviewers / users it will generate confusion.

9

Sure! I would reccomend you reduzing languages! :smile:

10

:rofl::rofl::rofl::rofl::ok_hand:

I will try, but It’s not my call. :yum:
My service is running 40 journals… and every editor can do whatever they like with their OJS.

But no matter the number of langs.
The multilangForNames problem persists with only two langs. :roll_eyes:

11

So long since we talk about this, so I’m wondering if:
a) is there any plan to improve it.
b) is there any workaround or indication to patch till we find a global solution.

Summarizing the post:
Is great to introduce multilang in names, but it not so great if it means it will makes UI/UX more confusing in journals that don’t require it feature (99% published with latin charset and names not changing between langs).
The proposal is add a setting (in config.inc.php or in a OJS settings) asking about how do you want to deal with people’s names.

At the end, what I’m trying to avoid here forcing our users to fill the same info N times (where N is the number of enabled langs), so another solution here is adding an extra “fake-field” where you can write your name once if it is the same in all langs (and fill/overwrite the other fields with some JS).

Proposal posted in github to talk further: [OJS] Improve UI/UX with names for multlang journals. · Issue #6291 · pkp/pkp-lib · GitHub

@NateWr please, let me know if you think this last idea have sense and you want help or if you have a better proposal.

12

I feel like this has already been addressed, but maybe I am missing something. I commented in the GitHub issue.

1 Like
13

I forget about this post and conversation was retaken here:

In this new post the starting point was an issue with primary_language, but ends with similar arguments than I exposed here.

Just to be clear about my argument: Most of the multilanguage journals don’t require i18n in user’s names, so the feature request is “why not making this optional”?

Nate, sorry to persist with this, but in our service this is becoming a major usability issue.

Thanks for your work.