Adding Submission, strange message OJS 3.1.0-1

Hello, I started to upload submission but I got the following message as on image below:
Screenshot_2018-04-03_22-06-44
Please advise

Hi @vvucic

What is the submission locale?

Best,
Bozana

Submission Language is English. When I change to Serbian there are many key messages that are not translated but they ARE translated.

Hi @vvucic

Those user group names, that are used in the file names, are in the DB table user_group_settings. It seems like they are as such, i.e. not translated, there, in the DB. Could you please take a look at that DB table to check that?
However, I wonder how come the English values are not there :open_mouth:
How file names are constructed has been changed in the recent 3.1.1 release – no user group is used.

Hmmm… For other missing translation I cannot tell much in general – I would need to see and investigate the specific/concrete cases.

Also, I do not see any possibility to reload that default user group values – e.g. if a locale is installed before those keys were translated, then later those keys are translated and one would like to have them then properly in the DB. Maybe I just cannot see that option.
When doing a locale default reload in the current 3.1.1 release the journal settings are reloaded for that locale, but not the user group settings.
@asmecher, do you know if the usage group settings default reload is/should be possible?

Best,
Bozana

Hi @bozana,

Yes, I believe there was a recent forum post about someone resetting to defaults successfully via the interface (and solving a missing translation problem that way).

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Bozana,

I checked how submission was made. Actually, the submission was made as Serbian language and translation did not appear although it exists. In addition, when it is changed to English no English messages are displayed. Maybe this helps to figure out more precisely where it is issue.

Thanks

Hi @vvucic

The message from your screenshot i.e. the displayed file name does not depend on the UI language but on the submission language.
Does the translation exist in the DB table user_group_settings?

EDIT: I still haven’t find the way to reload the default user group settings via UI, but report as soon as I do…
However see also: New translation: getting default values for email templates, article components and role names after upgrade to OJS3 and OJS3 French canadian translation - #3 by pnault

Best,
Bozana

Hello,

I do not see translation in user_groups_settings. It is strange since I translated everything.
There is only one change that can possibly cause this behavior. I moved xml files from 100% translated locale from OJS the same version to the server of this installation. Entry of submission had such message as result. I guess this should not be problem , but that is the situation.

Those translations are inserted into the DB when the journal is installed, thus if you copied the xml files after that, they cannot be in the DB…

Hmm. but , submissions added before I addedd XML do have everything needed as on image below:
Screenshot_2018-04-09_16-49-36
I think that something breaks those connections between locale of submission, database and locale translations.

hmm… are all translation missing in your DB table, or just for sr_RS?

Ah, and then those file names seem to be saved in the DB table submission_file_settings, so those translation seem to be missing in the DB table user_group_settings when those files were created… ?

Ah, and one more thing is happening: when migrating from OJS 2 to OJS 3 the file names are first generated considering the old locale sr_SR and later, at the end, the old locale is replaced with the sr_RS@latin. So this leads that “common.file.namingPattern” and “common.file.anonymousNamingPattern” are not found for the article files in sr_SR, thus those file names will be “##common.file.namingPattern##” and “##common.file.anonymousNamingPattern##”.
I’ll have to investigate it… eventually that migration to sr_RS@latin should happen first… :-\

Hello,
We have in that installation Serbian, French, English and Croatian language. English is primary locale. Croatian is missing a lot of translated message keys since, it seems to me, there is no anyone there to complete the work.
French locale is missing some but not much. I completed Serbian translation.

@vvucic, do you mean now the missing translation in the DB table user_group_settings, or also others?
Thanks!

When I see messages fro those locales I see keys that are not translated.

I think those untranslated file names in Serbian (for articles with locale = Serbian) are probably due to the ‘wrong’ migration position, s. place sr_SR migration before files migration · Issue #3563 · pkp/pkp-lib · GitHub. Could it be in your case @vvucic? – That those files were named so (with ##) after a migration?
Else, as I said above, if a file is created when there was no translation in the user_group_settings for that submission locale.
For other untranslated messages in the system I cannot say anything without the specific examples…

I still haven’t figured out where in the UI you could reload those default translations into the DB table user_group_settings… :frowning:

I do notthink that there is position wrong. locale.xml files are copied exactly where it is needed. I Jus tthink that the system is confused when reads new XML files but DB table user_group_settings has old values i.e. before copying newly translated XML files. That confusion makes strange messages. So, confusion sinot only due to new translations, but to something else because the same messages showed up properly before migration of new XML translated locales.

I mean: for the migration the sr_SR was changed to sr_RS@latin at the end of the upgrade process, i.e. the file names and the entries in the user_group_settings table were inserted considering sr_SR, which does not exist any more. Then at the end of the upgrade just the locale column is changed i.e. the string sr_SR is renamed to sr_RS@latin without updating the untranslated keys in that table user_group_settings. This is what I mean with the position: the sr_SR to sr_RS@latin migration function should be positioned at the beginning of the upgrade process, as in that GitHub issue. Then the file names and user roles/groups migration will consider the new sr_RS@latin instead of the old not-existing sr_SR locale.

Yes, when new translation comes, the user_group_settings is not updated/changed – those entries in the user_group_settings are filled only when a journal is installed (or at upgrade from OJS 2) and then they stay as they are.
If a file is created when those translations were missing in the user_group_settings, the file name with ‘##’ is saved in the DB table submission_files_settings, and it stays as it is.

I am trying to figure out your concrete example(s): the file from above has the name “nsimic, ##default.groups.name.author##…” because the sr_RS@latin translation of that key is missing in the DB table user_group_settings.
The other file, with the name “admin, Journal manager, …” used English locale which seems to be correctly in the DB table user_group_settings.
Earlier, in an earlier OJS 3 version, the file names were considering/using journal primary locale. That was not correct and was then changed for the files to consider article locale.

For new files that will be created in your installation, the translations in the DB table user_group_settings should be updated – it seems that some of them are now there i.e. exist in the xml files – but I do not know how i.e. I cannot find that option in the UI.

What do you mean with “the same messages showed up properly before migration of new XML translated locales”? Do you have an example?
I suppose those were correct because the entries for that locale were correct in the DB table user_group_settings?

Here is example of submission that admin entrered on behalf of author before that strange message occured.
Screenshot_2018-04-10_18-58-57

I think that some switching between locales in relationship of switchin local of submission is probably issue.