Changing default language impacts on user's given/family names

Software Support
, ,
1

Hi, sorry in advance if the answer is obvious or answered before.
I did a search in forum&github and I didn’t find anything related.

Description of issue:
On OJS 3.2.1-4 (probably in all 3.x versions), on a single-tenant journal (but I suspect also in multi-tenant) when I change from one default language to other (globally or journal level), default content keeps in the old language.

Even it makes a lot of sense for most of the fields, this is not the behavior a user will expect for others.

Let me explain this with an example:

Today a journal decided to move from Catalan (ca_ES) to English.
Once you make the change, all the fields that were not filled in English are requested (and this is fine because -for instance- config sections NEED to be filled explicitly in the new language) but this is not the best solution for other fields.

Most relevant example is user’s name and surname:

imagen

Where user will expect his default data would be replicated to (at least) the new default language.

If I check the DB, in “user_settings” the preferedPublicName is the same in all 3 languages (and I suspect it was done automatically by OJS), but familyName and givenName are not.

And things go wild when (as happened with this journal) they decide to disable the former default language (Catalan) because they won’t be able to see the former name any more.

As a workaround I modify the DB to copy ca_ES to en_ES and did the job.

The query to do this, would be: (use at your own risk)

INSERT IGNORE INTO `user_settings` (user_id, locale, setting_name, assoc_type, assoc_id, setting_value, setting_type)
SELECT user_id, "en_US", setting_name, assoc_type, assoc_id, setting_value, setting_type
  FROM `user_settings`
 WHERE locale = "ca_ES"

Extended comments:

This is related with the conversation we had sometime ago in gitHub about the internazionalization and the new approach ojs 3.x applied to user’s names. IMHO, the existing UI for adding i18n to user data is great over the paper but is not practical in real life. Multilanguage journals have also a niche, and most of the times, 99% of the users don’t need a translation for his/her name. I mean, it’s good offering those fields, but I think they must be propagated by default and let users change if they like… or better than this, only show extra fields is the user explicitly request for them. The world icon (green, red or gray) won’t need to warn user if he/she only set this once.

1 Like
2

I don’t think this is the case 99% of the time. There are a number of places where multilingual journals run in multiple character sets (eg - Cyrillic / Latin, Chinese / English, Arabic / English). In such cases, it would not be appropriate to copy user or author name data from one language to another.

I agree that the username handling makes for some uncomfortable UX. The givenName and familyName distinctions are important for author records. But I’d like to see users get by on just a preferred name, and one where they can override it in different languages but don’t need to. That’s a pretty hefty refactor, though.

3

I didn’t express myself.
You are right Nate, on journals with langs with mixed charsets the UI will work great because users will usually like to write their name in different languages.

But, what I wanted to say is not this.

I’m talking about journals sharing same/close charset (english, spanish, italian, french, portuguese…) that usually appeal to users of those same langs so 99% users won’t require to write their givenname/familyname in one lang and will find the UX confusing.

Some years ago I posted in gitHub explaining why I though it need to be rethought, but now I can’t find it. :frowning:

Anyway, in this post (alive from 2016 to 2020. longest post ever?) some fellows explains they are not happy with the existing solution too:

I can’t tell for sure how many journals include langs with mixing chars and how of them share (could we know with all the beacon work fellows are doing?) but I suspect it will be very related with regions: In a brute estimation I would say most of south-American journals and EU will use a single charset, and also for journals with a single lang, and mixure will be more common in boundary regions.

In our service (spain), in 50 journals we use a lot of langs, but one is asking for different charset (they include Chinese). I mean, I know this is just an example and PKP need to think it globally, but I’m just trying to explain that I think the dimension is big enough to spend some time to find, if not a solution, a work-around.

Cheers,
m.

4

I found it… it was not gitHub, was in this forum back in 2019:

Cheers,
m.