Hi
In our OMP setup, we have chosen a Danish and an English user interface. Danish is the primary locale. Our current version is 3.1.2.1
When our anthologies appear in the English UI, only one author name appears next to the individual chapters, even though several authors are registered. In the Danish UI everyone is shown. See:
How do I solve that problem?
Best
Niels Erik
Hi @nef,
Not sure, just guessing: Do all the authors have names in Danish and English?
Regards, Primož
Hi
Thank you for answering.
Usually we only use English for the UI and this is where I discovered the problem. To make it clearer, I exceptionally chose English in both forms and submissions in order to show the English and Danish in the image I have attached to my question, but now the setting is again set to English only in UI.
Therefore, all authors’ names should be included without being written in an English form and submission.
In the first years, we had only one English edition, but a few months ago, I translated the entire OMP program and we subsequently chose to run with the languages distributed as follows:
In the Catalog Entry the author names are missing too, See:
Regards
Niels Erik
Hi @nef,
Did the Primary Language change from English to Danish at some point, or was it always set to Danish?
[Cross-posted: Author names missing in OMP · Issue #5300 · pkp/pkp-lib · GitHub]
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher
Yes, the Primary Language changed from English to Danish. A few months ago I translated the whole OMP package and after that, we chose to have Danish as Primary locale.
Regards
Niels Erik
Hi @nef,
That’s similar to the situation described here:
https://github.com/pkp/pkp-lib/issues/5168
Changing the journal’s primary locale changes OJS’s expectations for that data will be present. With the primary language set to Danish, OJS will expect at least Danish data to be present, with other languages optional.
You should be able to provide the missing data with the following queries:
INSERT IGNORE INTO author_settings (author_id, locale, setting_name, setting_value, setting_type) SELECT author_id, 'da_DK', setting_name, setting_value, setting_type FROM author_settings WHERE setting_name='givenName' AND locale='en_US';
INSERT IGNORE INTO author_settings (author_id, locale, setting_name, setting_value, setting_type) SELECT author_id, 'da_DK', setting_name, setting_value, setting_type FROM author_settings WHERE setting_name='familyName' AND locale='en_US';
These will populate the Danish names (given and family) based on the English names, and the IGNORE flag will cause MySQL to move on when there’s already a Danish name present.
Please take a good backup before you run this, and test afterwards!
Regards,
Alec Smecher
Public Knowledge Project Team
Hello Alec,
Thanks for looking at this. I agree that the locale change is part of the issue. Unfortunately it does not seem to be the whole issue.
I’ve updated the installation that @nef is working on using the SQL you’ve shown adapted to Postgresql and en_US data is now replicated to da_DK.
Unfortunately we now seem to have the problem with contributors created after the switch of the primary locale. New contributors created on a submission, with da_DK as primary locale, are shown without givenName and familyName if the UI is then changed to english. I would have expected it to fallback to the data from the primary locale if there is no data for the selected UI language but that does not seem to happen.
For now I’ve replicated their da_DK data to en_US to ensure they show up correctly in the english UI.
Just to clarify – you’re running a multi-press installation, and some presses have Danish as a primary locale, and others have English as a primary locale?
Regards,
Alec Smecher
Public Knowledge Project Team
There is just one press and it now has Danish as the primary locale. It used to be English but we switched it over when @nef completed the danish translation.
Hi @tgc99,
Hmm, when OJS or OMP work with only a single press or journal some of the multi-press/multi-journal settings get hidden. I wonder if there’s a mismatch in some of the hidden settings. Can you try the following DB query?
SELECT * FROM site;
Regards,
Alec Smecher
Public Knowledge Project Team
omp3_prod=# select * from site;
redirect | primary_locale | min_password_length | installed_locales | supported_locales | original_style_file_name
----------+----------------+---------------------+-------------------+-------------------+--------------------------
0 | en_US | 6 | en_US:da_DK | en_US:da_DK |
(1 row)
omp3_prod=#
Looking at the press, it has the correct locale set:
omp3_prod=# select * from presses;
press_id | path | seq | primary_locale | enabled
----------+------+-----+----------------+---------
1 | aul | 1 | da_DK | 1
(1 row)
omp3_prod=#
Hi @tgc99,
I’d suggest setting the primary_locale setting in site to da_DK. You’ll need to flush your cache files after changing this manually. I’ve noted a few similar problems and will be filing this for further attention soon, but it’s a pretty uncommon change to make, so for the moment I think a manual fix would be best.
Regards,
Alec Smecher
Public Knowledge Project Team
I changed the site primary_locale to da_DK and flushed the caches and now it seems to correctly fall back to da_DK data in the english ui.
Thanks @asmecher
Hi @asmecher
sorry to dig this one up again, but we’re having the same problem with our OMP (3.3.0.8) - the primary locale of the press is set to German, with English as a secondary locale. We typically only ever enter contributor given and last names in one language field, because OMP allows us to do this and because everywhere else, it defaults to inputting a title/abstract/etc from the default language if the only other option would be to leave the field empty.
However, for chapter authors, and ONLY for chapter authors (editors are shown in the main contributor field in both language frontend versions), they are simply missing in the English frontend.
I saw your solution above, but as we run a multi-press installation where every other press uses English as its primary locale, it’s simply not feasible for us. Any advice would be appreciated!
Best,
Pia