Fixed translation cache access when the translation content is changed

[gushil]

Closes #

The problem occured when editing the form (that already submitted before) and the page with multiple selectpickers in repeating group is always showing the wrong select text.

From my observation, it is caused by selectpicker using i18n translation with i18nNumber involved.
We will have same translations for all selectpicker widgets because all widgets have same i18n data eventhough it has different i18nNumber.

This select instances

<group_nm7ec42  enk:ordinal="1" >
	<multiselect2>a b c</multiselect2>
</group_nm7ec42>
<group_nm7ec42  enk:ordinal="2" >
	<multiselect2>a b</multiselect2>
</group_nm7ec42>

will give us

It is supposed to give us

I have verified this PR works with

• Online form submission
• Offline form submission
• Saving offline drafts
• Loading offline drafts
• Editing submissions
• Form preview
• None of the above

What else has been done to verify that this works as intended?

Why is this the best possible solution? Were any other approaches considered?

The solution that minimize cache key access, translation call and just adding one string comparison.
Already tried the solultion in selectpicker but that is not an optimal one.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

I don't think there is any. All tests are passed.

Do we need any specific form for testing your changes? If so, please attach one.

No.

[MartijnR]

Hi Agus,

I was actually not going to review this (because I only agreed to review the filename issue) and just suggest you create a PR for enketo/enketo since it looks like this is not related to an OpenClinica customization.

However, I couldn't help peaking inside, and made a comment after all...

Still, I'd recommend continuing this work in enketo/enketo, and wait for somebody there to review it. Of course, you'd have to first confirm that the issue indeed occurs in enketo/enketo and perhaps add an issue for it there. The BIG advantage for yourself is that if they implement their own fix some day, it would create a painful merge conflict. Moreover, it is also the right thing to do, in my opinion.

[MartijnR]

Looks good with a chance to simplify further.

I only looked at the code, didn't try to reproduce the bug or test the fix.

I recommend offering the next version to enketo/enketo for their review and also file a bug report there. I think this would be a welcome fix for a bug! 👍

[MartijnR]

Is the translationKey variable actually necessary? This might just be el.dataset.i18n.

[gushil]

Created PR in upstream (enketo/enketo) to fix this issue.

enketo#1336

Thanks.