PKP Bugzilla – Bug 5816
language settings for submissions
Last modified: 2012-09-21 15:59:03 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.
Language settings for submissions and forms are not functioning properly: no matter what are the settings for submissions, the settings for forms are considered and the result is the same.
Primary language is English.
1. German is selected for forms:
Then the result is the same for both settings for submissions
a. German is selected for submissions,
b. German is not selected for submissions
In both cases there is the language pull-down in all forms (also in the submission forms in case b.) and all forms can not be saved if there is no data (filled in) in English.
2. German is not selected for forms:
Then the result is the same for both settings for submissions
a. German is selected for submissions
b. German not selected for submissions
In both cases there is no language pull-down in any form (also not in the submission forms in case a.) and everything (filled in) is accepted (both for submission and other forms) and saved in/as English.
In general, the language settings for forms function like this:
If a language is selected for forms, there is the language pull-down in the forms and the form has to contain data (filled in) in the primary language.
If a language in not selected for forms, there is no language pull-down in the forms and the data (filled in) is always (also using this language in UI) accepted and saved in/as the primary language.
Either the language settings for submissions is considered totally separately from settings for forms (and would in this case behave like settings for forms in general, described above /* and 'submissions' means in this case author submissions, so that editors can change and correct the submission metadata later */) or at least the example 1b. should be considered differently (in order to avoid the problems that authors have when the error message appears and they are asked to fill the data in the primary language).
Created attachment 3198 [details]
Patch against OJS pre-2.3.3
Completed separation of form locales from submission locales. (I thought I'd already finished this, but must've dreamed it.)
Commit for PKP lib: http://github.com/pkp/pkp-lib/commit/c3f2c3edf57c6508ae5c57b908ebbdce386f8e3d
Needs porting to OCS and OMP.
Using this patch against 2.3.2-1 gave us the output below in a "dry-run", we have a couple of journals that are coming online and are now accepting submissions in various languages other than English and are very anxious to have the submission forms working just right. Any idea when this patch will be included in a release? As this is a fairly large patch and obviously needs to be hand reviewed on our system pretty heavily is it ok to apply on a 2.3.2-1 system? I also had to also remove the following lines to get the patch to fully work as "patch" reported it could not patch the directory /lib/pkp. Please let me know.
<!-- BEGIN -->
diff --git a/lib/pkp b/lib/pkp
index bd9c2f1..c3f2c3e 160000
@@ -1 +1 @@
-Subproject commit bd9c2f1aacdb55367d729e2034ca0e9e36380c9e
+Subproject commit c3f2c3edf57c6508ae5c57b908ebbdce386f8e3d
<!-- END -->
# /usr/local/bin/patch -p1 --dry-run < /usr/local/journals/OJS-PATCHES/5816.patch
patching file classes/author/form/submit/AuthorSubmitForm.inc.php
patching file classes/author/form/submit/AuthorSubmitStep1Form.inc.php
Hunk #1 succeeded at 22 (offset 2 lines).
patching file classes/author/form/submit/AuthorSubmitStep2Form.inc.php
patching file classes/author/form/submit/AuthorSubmitStep3Form.inc.php
Hunk #1 FAILED at 20.
Hunk #2 succeeded at 120 (offset 1 line).
1 out of 2 hunks FAILED -- saving rejects to file classes/author/form/submit/AuthorSubmitStep3Form.inc.php.rej
patching file classes/author/form/submit/AuthorSubmitStep4Form.inc.php
patching file classes/author/form/submit/AuthorSubmitStep5Form.inc.php
patching file classes/author/form/submit/AuthorSubmitSuppFileForm.inc.php
Hunk #1 FAILED at 33.
1 out of 2 hunks FAILED -- saving rejects to file classes/author/form/submit/AuthorSubmitSuppFileForm.inc.php.rej
patching file classes/submission/common/Action.inc.php
Hunk #1 FAILED at 54.
Hunk #2 FAILED at 76.
2 out of 2 hunks FAILED -- saving rejects to file classes/submission/common/Action.inc.php.rej
patching file classes/submission/form/MetadataForm.inc.php
Hunk #1 succeeded at 33 (offset 2 lines).
Hunk #2 succeeded at 68 with fuzz 2 (offset 2 lines).
patching file classes/submission/form/SuppFileForm.inc.php
patching file pages/author/SubmitHandler.inc.php
Hunk #2 succeeded at 44 with fuzz 2.
Hunk #3 succeeded at 59 with fuzz 2 (offset -1 lines).
Hunk #4 succeeded at 69 with fuzz 2 (offset -1 lines).
Hunk #5 succeeded at 77 (offset -1 lines).
Hunk #6 succeeded at 109 (offset -1 lines).
Hunk #7 succeeded at 143 (offset -1 lines).
Hunk #8 FAILED at 170.
Hunk #9 succeeded at 186 (offset -5 lines).
Hunk #10 FAILED at 197.
Hunk #11 FAILED at 217.
Hunk #12 FAILED at 241.
4 out of 12 hunks FAILED -- saving rejects to file pages/author/SubmitHandler.inc.php.rej
patching file pages/author/TrackSubmissionHandler.inc.php
Hunk #2 succeeded at 203 with fuzz 2.
Hunk #4 succeeded at 340 with fuzz 1.
patching file pages/copyeditor/SubmissionCopyeditHandler.inc.php
Hunk #1 FAILED at 249.
1 out of 1 hunk FAILED -- saving rejects to file pages/copyeditor/SubmissionCopyeditHandler.inc.php.rej
patching file pages/layoutEditor/SubmissionLayoutHandler.inc.php
Hunk #2 succeeded at 115 with fuzz 1.
Hunk #3 FAILED at 132.
Hunk #4 succeeded at 357 (offset -3 lines).
Hunk #5 succeeded at 371 with fuzz 2 (offset -3 lines).
Hunk #6 succeeded at 379 (offset -3 lines).
Hunk #7 FAILED at 399.
Hunk #8 FAILED at 424.
3 out of 8 hunks FAILED -- saving rejects to file pages/layoutEditor/SubmissionLayoutHandler.inc.php.rej
patching file pages/proofreader/SubmissionProofreadHandler.inc.php
patching file pages/reviewer/SubmissionReviewHandler.inc.php
patching file pages/sectionEditor/SubmissionEditHandler.inc.php
Hunk #1 succeeded at 821 with fuzz 1 (offset -19 lines).
Hunk #2 FAILED at 1216.
Hunk #3 FAILED at 1240.
Hunk #4 FAILED at 1285.
Hunk #5 FAILED at 1309.
Hunk #6 succeeded at 1413 (offset -23 lines).
Hunk #7 succeeded at 1422 (offset -23 lines).
Hunk #8 FAILED at 1746.
5 out of 8 hunks FAILED -- saving rejects to file pages/sectionEditor/SubmissionEditHandler.inc.php.rej
Brian, this will be difficult to back-port to previous versions. Fortunately we're just working on final testing and translation of OJS 2.3.3 and these changes will be released in that version. I'd suggest waiting until it's available sometime in September; if you're able to help testing the pre-release code, that would be very helpful.
See bug #5830 for a fix to attachment #3198 [details].
We are very willing to do some testing here on at least one our test instance since we have roughly 6 journals with multiple languages setup. And we have one that is VERY anxious to move along with getting this fixed. Each of our journals is setup in a separate installation of OJS so that we can do code upgrades/updates/patches/hacks/etc. per journal separately. This allows us to throw new ones up quickly as well. Apache Virtual hosts help us a lot. ;-)
I did see some code changes in the patch that are not in the stock 220.127.116.11 so I wasn't too optimistic about the existing patch working out of the box. And after some testing it actually doesn't ;-) so I'll be rolling back the code here in a few minutes.
Let us know about testing the code for you.
Excellent, Brian. If you're handy with Git, there are instructions for checking out a fresh copy at http://pkp.sfu.ca/wiki/index.php/HOW-TO_check_out_PKP_applications_from_git -- this is the best way to work with pre-release code as it'll be easy for you to update your install with any code that changes as a result of this discussion.
We're very interested in getting these changes right, and are working on it right now, so if you have a chance to get us feedback in the next few days (!!) it would be very timely.
I'm not personally very familiar with git, but using git and your instructions, I have "cloned" my forked copy of ojs to our server here. I'll look about getting it tested here sometime soon if possible. There is a little overhead needed to get a new DNS CNAME added to the machine through our network group here. Once added I should be able to bring a 'git' copy up and running quickly so that we can, so to say, 'git-r-done'. ;-)
If we are not able to test it and let you know ASAP, I'll let you know.
After some quick testing we found that in step #3 of a author submission, that the systems still wants Titles and Abstracts in English (which is the Primary Language) on the site, however the author has chosen French. So I guess the system is insisting on making sure that there is a "copy" in English. Is there a way to allow submission without forcing the system to have a "Primary Language" "copy"? In one of our journals they wish to allow submission in French or English so both are considered "Primary Languages".
Also, we noticed that by default the "Indexing" also was defaulting to "en" instead of using the author's chosen language "fr". Is there a way for that to be selected automatically per the author submission as well as obviously if they are using the French form they most likely are entering French metadata, thus switching the indexing to French makes sense.
Anything else we should know or if we need to make some system changes to get the above to work, let me know.
Brian, (and Bozana, of course), thanks for the effort you're putting into this -- I'll have time today and tomorrow to refine it further and appreciate your help with testing and suggestions.
Brian, check your journal's language settings and see what you've allowed under "Submissions" -- those are the languages from which the author can choose a submission language at the beginning of the submission process. Once that language is chosen, they are required to enter necessary fields (e.g. Title) in that language, though others may also optionally be supplied too.
I've corrected the language field's default to use the locale specified at the beginning of the submission process; in a future release we should consider removing that field entirely in favour of the value chosen from the pull-down, but I'd rather not introduce that change so late in the testing process for this release.
I checked on our Journal's Language Settings, and under Home->User->Journal Management-> Languages we have set the following:
Primary Locale: English
English UI(checked) Submissions(checked) Forms(checked)
Francais UI(checked) Submissions(checked) Forms(checked)
So what I think should happen is that by default the web site should be in English, then upon selection of the user it can be shown/used in French.
It should also then allow either submissions in English OR French with no requirement for English needed (which is currently not the case). This could be desired in some journals but not others as I can see some journals requiring an English or other language version regardless. But the selection should be a setup choice for the journal.
I feel that there should be a "Required" check box under supported locales for the "Submissions" for each language (to require a submission in that language) in addition to there also being an option to be able to submit under "Any" language meaning at least one the selected languages must be used.
I hope this helps.
Brian, what you describe in comment #11 is how things should currently function -- on Step 1 you can choose a submission locale from a pull-down (i.e. English or French), regardless of the current UI language. That should define the "required" language for fields like "title". If it's not working that way, could you check the "locale" field of the "articles" table for that submission and tell me what it is? Also make sure your git checkout is current, i.e. run "git pull official master" in both the OJS directory and the lib/pkp subdirectory. (You may need to also run "php tools/upgrade.php upgrade" after running the git update.)
(In reply to comment #12)
> Brian, what you describe in comment #11 is how things should currently function
> -- on Step 1 you can choose a submission locale from a pull-down (i.e. English
> or French), regardless of the current UI language. That should define the
> "required" language for fields like "title". If it's not working that way,
> could you check the "locale" field of the "articles" table for that submission
> and tell me what it is? Also make sure your git checkout is current, i.e. run
> "git pull official master" in both the OJS directory and the lib/pkp
> subdirectory. (You may need to also run "php tools/upgrade.php upgrade" after
> running the git update.)
Newest code download seems to have fixed the issue with author submission, however, note that while in step#3 submitting the "Browse" button was only in English, while the "Upload" button was in the chosen language (in our case French). Also there was one additional text on Step#1 that wasn't defined: ##author.submit.submissionLocale##
I hope this helps. Let me know if you have any other questions.
Thanks, Brian. The missing locale key is OK -- we're currently waiting on French language updates -- and the "Browse" button's label is fixed by the browser, unless we go to something like a Flash-based file upload widget. Glad to hear it's working OK otherwise. One tweak I will make: the form language pulldown will default to the locale chosen on the first submission step.
Created attachment 3223 [details]
Additional patch against OJS pre-2.3.3
Improved default selection for the form locale. Brian and Bozana, would you be able to run this through a final test to see if it'll be less confusing for authors etc.? I'll do some testing here as well.
(In reply to comment #15)
> Created attachment 3223 [details]
> Additional patch against OJS pre-2.3.3
> Improved default selection for the form locale. Brian and Bozana, would you be
> able to run this through a final test to see if it'll be less confusing for
> authors etc.? I'll do some testing here as well.
I'll give a look when I get back to the office Tuesday or Wednesday.
(In reply to comment #16)
> (In reply to comment #15)
> > Created attachment 3223 [details] [details]
> > Additional patch against OJS pre-2.3.3
> > Improved default selection for the form locale. Brian and Bozana, would you be
> > able to run this through a final test to see if it'll be less confusing for
> > authors etc.? I'll do some testing here as well.
> I'll give a look when I get back to the office Tuesday or Wednesday.
This should be applied to like a 18.104.22.168 system and not a GIT version correct?
Let me know,
Brian, this would be a current git checkout -- the 2.3.2 version is sufficiently far behind that it'd be difficult to bring it up to date with patches.
It seems to be working as expected. We ran through a submission and languages stuck where they were supposed to and when switching between languages the content changed as well.
Hope this helps.
Excellent -- thanks for all the help, Brian and Bozana. Leaving open for back-porting to other apps. (Note also bug #5907.)
Is Bug 4144 effectively a dupe of this one? We haven't yet ported over the "submissions" multilingual distinction to OCS (or probably OMP) yet, IIRC.
James, this entry is a better solution to the same issue discussed in bug #4144. It does still need porting to OCS.
*** Bug 4144 has been marked as a duplicate of this bug. ***