PKP Bugzilla – Bug 4144
Consider allowing any locale field entry to satisfy mandatory field check
Last modified: 2011-10-31 11:02:19 PDT
We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.
This issue has been reported a couple of times, and I may actually be missing a previous bug report. Multilingual conferences may receive presentations for which information is not readily available in the default locale; ie., conferences with the default locale es_ES but also supporting pt_BR and en_US may receive submissions in pt_BR only, in which case the presenter will have to either translate the title/abstract, or will have to enter their pt_BR information into the es_ES fields.
I think the most satisfying solution would be to keep the status quo as the default, but allow for an optional, more relaxed check, where if the Conference Manager wants, any information in any locale will satisfy the mandatory check. Of course, the issue then becomes what to display for the default locale if no information is given ... to which I have no answer.
This will involve quite a bit of tricky SQL rewriting -- it's too late for it to get into this release. Might even be best for 2.3.
Deferring to 2.3.
Is this issue being dealt with in 2.3?
The translation "should not be" an author's responsibility, although he could provide if desired.
OxS should define the input to be the default locale, although the fields are entered in another language (ie: journal in portuguese, accepts submissions in english).
The problem is that the interface displays the form language in the language selected, instead of the default language.
When an english-speaking author enters a submission to this portuguese journal, and he changes the interface to english, that's the language defined as the form's language.
When saving the form, OxS complains that title and abstract must be informed in the primary locale (Portuguese (pt_BR)).
If the form displayed the default language as the form's language, most of the problems would be fixed.
A plus would be to copy the data to the other languages, to facilitate translation later on...
Another option is, if you don't want to change the form language issue (displaying the language of the interface as the form's language), then the mandatory fields should be copied to the other languages, especially to the default language, which may be a faster solution...
Ramon, have a look at the new Journal Manager's "Languages" form in OJS 2.3 -- this may not be a complete solution, but might help. If you have a journal that you want to operate in several languages from a UI perspective, but for which authors should only be able to enter a single language, you can now choose UI languages separately from form languages. If you want to mix English and Portuguese, for example, you can now do that -- the downside (needs more consideration) is that OJS won't know what is English and what is Portuguese.
Deferring. (The UI / Forms language distinction in 2.3 helps address this; more consideration needed for further changes.)
Agreed that this needs further consideration. I think we need some special handling on article metadata. There are many cases where translations are added in later on, so the multi-lingual forms are needed, but the primary language on submission should not be a requirement.
I"ve seen this in most of the journals in latin america. everyone has a problem with how we've handled this. lets talk to Brent about ideas.
(In reply to comment #5)
> Ramon, have a look at the new Journal Manager's "Languages" form in OJS 2.3 --
> this may not be a complete solution, but might help. If you have a journal that
> you want to operate in several languages from a UI perspective, but for which
> authors should only be able to enter a single language, you can now choose UI
> languages separately from form languages. If you want to mix English and
> Portuguese, for example, you can now do that -- the downside (needs more
> consideration) is that OJS won't know what is English and what is Portuguese.
I tried this in OJS 2.3.1-2, but it didn't work. My default journal language (Primary locale)is German and the author has choosen English as UI, but not as form-language. With an English surface, the author gets the same error (as described in comment 3), that the system wants title and abstract in the primary locale.
This is also very urgent for us, because the authors complain.
Birgit, what settings have you chosen for the Journal Manager's "Languages" page?
(In reply to comment #9)
> Birgit, what settings have you chosen for the Journal Manager's "Languages"
I have choosen:
Primary locale: deutsch (Deutschland)
Deutsch: with UI and Forms selectet (the system shows this, I can't change this, to select only UI is here not possible, makes no sense)
English: only UI selected
If I publish an article with the english interface, I get the following error messages:
"Please enter the title of your article. (Deutsch (Deutschland)) "
"Please enter the abstract of your article. (Deutsch (Deutschland))"
Could you help us?
Birgit, this is currently by design. It's mandatory to enter data in the required fields in the language you choose as your "Primary Locale". We're currently considering ways to make this less problematic for users who are browsing in a language other than the primary locale, but that is probably a few releases away at the moment.
Should this bug be reopened or should a new one be entered? We're still getting a fair number of requests for this kind of behaviour.
One further general comment on this bug (which may in and of itself be considered a separate bug report?): Journal Managers should also be able to configure the language check the other way -- that is, they should be able to relax the language check so that users can add mandatory information in any language; and should also be able to strengthen the check so that users must enter all mandatory information for all languages.
James: alec is currently doing some work on multilingual stuff with some specs from Brent. Keep an eye out for those changes coming to OMP very shortly, and hopefully/probably rolled out to the other apps soon. I am not sure if the implementation will address these issues, but I think/hope it does.
I had the same problem that everybody described above. I am using OCS 2.3.2 that it is similar to OJS, when someone try to submit a proposal in the step 3, the system has problems when the language isn't the mandatory.
I made the following chages in the file ocs/classes/author/form/submit/AuthorSubmitStep3Form.inc.php:
Comment the lines:
32> $this->addCheck(new FormValidatorLocale($this, 'title', 'required', 'author.submit.form.titleRequired'));
38> $this->addCheck(new FormValidatorLocale($this, 'abstract', 'required', 'author.submit.form.abstractRequired'));
Add the lines:
33> $this->addCheck(new FormValidatorArray($this, 'title', 'required', 'author.submit.form.titleRequired', null));
39> $this->addCheck(new FormValidatorArray($this, 'abstract', 'required', 'author.submit.form.abstractRequired', null));
Now, the form validate if there are title and abstract only, and the authors don't have to change the language form. It works for me and my conference, I hope it could help you.
*** This bug has been marked as a duplicate of bug 5816 ***