After upgrading all content seems to be in place. Back issues are available. The issues’ submissions are listed correctly. But there are spelling mistakes and missing characters in some old article metadata fields.
I am logged in as administrator. I have given my user all roles.
I can add issues. I can add submissions to that new issue using quicksubmit and add contributors and galleys.
Looking at one specific submission for a 2008 issue I notice that there are characters missing in the Abstract and Author name (probably encoding mistakes from way back). Submission 111.
I unpublish the submission to fix the mistakes.
I fix the broken/missing characters in metadata. Trying to save it tells me “The form was not saved because 1 error(s) were encountered. Please correct these errors and try again.”
I click “Jump to error” next to “Please correct one error”. It stays on the metadata page, and there are no apparent errors, so there is nothing to fix. The text fields are half width as if there should be a second language there, but I have only one language activated.
The contributor was wrong so I removed that entry to add the correct one, after filling out all fields OJS tells me “A given name is required. ()*”. I have supplied a name so that means the only thing I can do is cancel.
Now I cannot re-publish the submission.
I could create a whole new submission using quicksubmit, which works, but that would change the article ID causing any old links to this article to stop working (which could be fixed by using a htaccess rewrite rue, but I’d rather avoid this if I can).
I fix the broken/missing characters in metadata. Trying to save it tells me “The form was not saved because 1 error(s) were encountered. Please correct these errors and try again.”
This sounds to me like the form is submitting data for a locale that is not supported. I think you may have said elsewhere that you’ve deactivated some languages.
Can you try going to Settings > Website > Setup > Languages and try to enable/disable the languages again as needed. Maybe something got mangled in your language settings during upgrade.
If you can inspect the database, you can also use the following query to identify issues with your locale settings:
select * from journal_settings where setting_name LIKE '%locale%';
The journal in question has all languages enabled. Norwegian set to default. I can also run the query, but I do not know what to look for or change. Pasted below:
The locale column is empty. Turning locales off and on has had no effect. I want just one language for the site (Norwegian), but need to be able to set the correct languages for the submissions. Do I need locales for all article languages or can it be done with just a code as in OJS2.x?
Side note. Could I cheat by re-adding the submission through quicksubmit which does work (giving it a new article number) and the changing the article number in the database? Or is it references too many times to make this a practical solution?
I want just one language for the site (Norwegian), but need to be able to set the correct languages for the submissions.
So you publish submissions in more than one language? Unfortunately, these languages do need to be enabled. That’s because the article data (title, abstract, etc) is all attached to a locale. Putting an English title into a Norwegian field, for example, will lead to inaccurate metadata going out.
Is that not pretty normal for a scientific journal (apart from, I suspect, English journals who accept only English language submissions)? We publish several journals that accept articles in Norwegian, Swedish, Danish, English and German. So for each of those we need to install 5 locales. And for each field, including Given Name and Surname (as if the persons name changes depending on what language the article is written in), we get five input field. Case: A German scientist submits an English language paper to our journal, which has Norwegian as it’s main and editorial language. We submit the article, telling OJS it’s in English. Do we enter his/her name in the German field and leave the other fields blank, and the Title in the English field and leave the other four blank? The file/galley name needs to be entered five times, because none of the fields can be blank. But the Title is the same for all five, as the article has not been translated. I can’t sit here making up titles for all four languages that are “missing”. To me as a user this makes no sense. Five times the work, five times the information. Instead of one language (the journal’s editorial language) and a code to let OJS know what language the article is in.
Still struggling with this. Un-publishing an article to fix metadata ends up with an error and can’t re-publish it. Re-adding it as a new submission works, but gives it a new submission ID which breaks all reference links to said article. Unless there is a way to give this new article the old ID it is not a tenable solution.
I have checked that the language settings are the same as they were for this journal post upgrade (2.4.7->3.2.x).
Each submission has a locale property which defines it’s primary locale. So in the example that you gave (German scientist submits in English), the submission locale should probably be en_US.
All required metadata for the submission must have values in en_US, so in this case you’ll need to enter the author’s name in English (since German names use the same latin characters, the German name should be able to be shown in English without any issues – not the case, for example, with Japanese or Arabic, where you would need to contact the author or, in the case of back issues, get a translation).
You shouldn’t have to enter any metadata in any languages other than the submission’s primary locale. But the UI will show fields for all languages so that you can if you want to.
When a reader is viewing the published article, and is viewing the site in German, the UI will first look for submission metadata like title and abstract in German (de_DE). If it can’t find the metadata in German, it will fall back to the submission’s locale (en_US).
Hey Nate. Yes that is the defense for why it is as it is. And it will leave thousands of empty fields in the database. But if that doesn’t break anything, no-one will ever notice. If we had an international journal that accepted articles in 50 languages doing it this way would make OJS unusable with 50 fields popping up every time you wanted to enter anything, but for now I can overcome 5 fields when needing just 1.
But my main issue persists. Can’t figure out what prevents me from editing metadata, or adding contributors for back issues, when submitting new articles (including use of quick submit works) and even encodes correctly.
I suspect it has something to do with all these articles having been submitted in 2.4.7 using quicksubmit.
Yeah, our multilingual support is not really intended for use this way. The majority of our use-cases are bilingual, or sometimes trilingual, journals. And often they publish translations, so that at least article metadata is published in both languages.
prevents me from editing metadata
Given the error message where it says there are X errors and then you click but it doesn’t take you to an error, I suspect there is data being submitted in the request for a language that isn’t supported. The system is supposed to strip out data from unsupported locales when it retrieves it for submission, but it’s possible additional data is in there muddying things up.
Looking at your supportedSubmissionLocales, it looks like data should be accepted in the following locales: nb_NO, en_US, da_DK and sv_SE. Using your browser’s dev tools, try to inspect the XHR request when the metadata is submitted to see if data is being submitted with a different locale key. You can also inspect the response, which may include a locale key with the error message.
Not sure where to see XHR data. I’m on Safari. Console shows: [Error] Failed to load resource: the server responded with a status of 400 (Bad Request) /index.php/journal/api/v1/submissions/1637/publications/1593
We made an erroneous upgrade from OJS 3.1.2 to 3.2.1 where we saw something similar in our installation. We actually only noticed it after upgrading all of our three instances. So here is what I would suggest checking:
Is your database-collation different than the collation of any tables in your database?
Do the collations of the tables email_templates_settings, publication_categories, publication_settings, publications, publication_galley_settings, publication_galleys differ from those of all other tables?
If that is the case, then there is no easy way to fix the mess that was caused by the upgrade. You would have to fix every missing character within all those talbes manually. The characters are not scrambled or changed to anything recognizable, they are replaced by literal “?”, iirc. You did not mention seeing “?” though, so I might be on the wrong track here.
We did a rollback of the upgrade because of this. All our tables were utf-8, but the database was set to latin-1. Another upgrade on one of our instances looks fine with changing the database collation before doing the upgrade.
Hello @NateWr I am also having this problem, what solution do you suggest, I have tried all the above. @geirrosset were you able to solve this issue and how?
Thanks @Simeon_Amoo, that’s perfect. I can tell from the second screenshot that there is some issue with abstract data that is not assigned to any locale. Where it says:
{abstract: {"": ["Please..."
There should be a locale key there:
{abstract: {"en_US": ["Please..."
I’m not sure how this could come about, but let’s examine a couple of settings. Are you able to run some SQL queries against your database? If so, can you run the following (replace <JOURNAL ID> with the ID of your journal):
SELECT * FROM journal_settings WHERE setting_name LIKE '%Locales%' AND journal_id=<JOURNAL ID>;
Hmm, well that looks like it should, so the error is not there. My next guess is that there is some stray information in the database that is getting pulled out, and it makes its way through into the request. Let’s search for any abstract data that isn’t assigned to any locale:
select publication_id from publication_settings where setting_name='abstract' and (locale='' OR locale=NULL);
If you get any matches, this indicates abstracts that are not assigned to a locale. You can check to see if this publication has other abstract information already:
select locale,setting_value from publication_settings where setting_name='abstract' and publication_id=<PUBLICATION_ID>;
If it already has the abstract information you expect, and its assigned to the correct locale, you can remove the abstract data that isn’t assigned to a locale. Otherwise, you may need to assign the abstract data to a locale to fix it.
