Required secondary locale check bug for multilingual input fields in submission steps

[Minoru_Tanabe]

Dear PKP staffs and Forum members,

I am currently operating OPS3.3.0.8 (PHP7.4).
On the submission step 3 (metadata input) form, the primary locale (“ja_JP”) is required for input fields such as the title, abstract, and keywords, but the secondary locale (“en_US”) is not required.
ex.) In case of title field
./lib/pkp/templates/submission/submissionMetadataFormTitleFields.tpl

        {fbvFormSection for="title" title="common.title" inline="true" size=$fbvStyles.size.LARGE required=true}
                {fbvElement type="text" multilingual=true name="title" id="title" value=$title readonly=$readOnly maxlength="255" required=true}
        {/fbvFormSection}

As above, “multilingual=true” and “required=true” are specified, but input a value in the title field of the primary locale, skip the title field of the secondary locale, and proceed to the next item (abstract, etc.) When skipping, the mandatory check for the title field in secondary locales is not applied. Also, pressing the [Save and continue] button does not result in an error.
On the other hand, if you click the title input field of the secondary locale or focus the title input field with a tab key, the mandatory check will be applied.

How can I get the required checks for both primary and secondary locales even if I skip target fields for secondary locales?

Best regards,
Minoru Tanabe.

[asmecher]

Hi @Minoru_Tanabe,

I believe this is issue 7369. Our software is designed to require metadata to be provided in the primary language only, with other languages being optional; the fix for this will be to make the application consistently require only one language. If you’d like to require metadata in multiple languages, you’ll need to modify the code to do that.

The fix for issue 7369 is scheduled for inclusion in OJS/OMP/OPS 3.3.0-14, which I hope will be released within the next few weeks.

Thanks,
Alec Smecher
Public Knowledge Project Team

[Minoru_Tanabe]

Dear @asmecher,

Thank you for your useful support.
I think what we are requesting is closer to issue 7369.
We would like to be able to choose whether the secondary language metadata entry fields are required or optional depending on the posting language.

As far as the fix for issue 7369 is concerned, I found it very difficult to modify the source code for the version we are using (OPS3.3.0.8).
In addition, we have customized OPS3.3.0.8 extensively and extensively, so we can’t upgrade immediately, so it seems that we have no choice but to modify the relevant parts individually.
We are considering whether to customize this matter individually, or to override the customized parts after upgrading to OPS3.3.0.14 (although it will surely be a considerable amount of hard work).

So, if we choose the former, should we only reflect the modified part of the source in 3 items below of issue 7369?

• pkp#7369 Multilingual text input field required validation
• pkp#7369 updated primary locale deduction based on submission process
• pkp#7369 Update file uploading functionality to handle submission primary locale to set file name and validation

Best regards,
Minoru Tanabe

[asmecher]

Hi @Minoru_Tanabe,

The proposed changes we’re expecting to include in OPS 3.3.0-14 are coded here:

pkp/pkp-lib#7369 Multilingual text input field required validation

Note: The steps below involve applying pre-release changes; please take a backup of everything before proceeding, and I recommend doing this in a test environment first!

I tested applying these changes to OPS 3.3.0-8 using the following…

cd /path/to/ops
cd lib/pkp
wget -q -O - "https://github.com/pkp/pkp-lib/pull/8440.diff" | patch -p1

…and there were a couple of conflicts:

patching file classes/form/Form.inc.php
patching file classes/form/FormBuilderVocabulary.inc.php
Hunk #1 FAILED at 422.
1 out of 1 hunk FAILED -- saving rejects to file classes/form/FormBuilderVocabulary.inc.php.rej
patching file classes/submission/form/PKPSubmissionSubmitStep3Form.inc.php
Hunk #1 succeeded at 58 (offset -10 lines).
patching file controllers/wizard/fileUpload/FileUploadWizardHandler.inc.php
patching file controllers/wizard/fileUpload/form/SubmissionFilesUploadForm.inc.php
patching file templates/controllers/wizard/fileUpload/form/submissionFileMetadataForm.tpl
patching file templates/form/textInput.tpl
Hunk #1 FAILED at 25.
1 out of 3 hunks FAILED -- saving rejects to file templates/form/textInput.tpl.rej

Each of two failures was a very minor conflict and quickly reconciled by applying the changes in the .rej files manually.

I do recommend figuring out how to reconcile your fork with the official releases of the code. The longer you spend making modifications to your fork, the harder it will eventually be to move back later, especially if you’re not tracking your changes individually e.g. in a git repository.

Thanks,
Alec Smecher
Public Knowledge Project Team

[Minoru_Tanabe]

Dear @asmecher,

Thank you for your proposal and pointing out the specific changes and the patch command.
We have customized 3 of the 7 files to be changed, so we would like to restore them to the default, apply this patch, and then modify them individually again.

If there are any unclear points during the work, I will ask you a question again.

Best regards,
Minoru Tanabe