Try our conversational search powered by Generative AI!

Episerver Forms: Multiple or single choice option list not localized



Our customer when configuring Episerver Forms defined couple of form elements including "Multiple or single choice" element with list of options (Items property), after that he wanted to translate the form to another language and everything was fine except of the fact he was not able to define Items for "Multiple or single choice" (property not localized) so it was shown in language version in main language.

We have changed that property to be localized in admin mode but realized that when we started to use for Items different values in language version than in original one when submitting form user got error  "Unexpected value is not accepted."

The solution (or rather workaround) was to use same values for the Items as in original language (just changing the Choice value for language specific) which was acceptable in that solution, but I can imagine that there might be cases when it is not acceptable (e.g. when you send chosen value via email with placeholders it adds the value to the email, so not localized text)

Another way how it could work I believe would be to create separate element for each language (I guess then there is no issue with different values), but then we lose all the benefits from language versioning.

I would like to know what is the recommended way of localizing Items for Multiple or single choice so we are not in risk that will be broken with some update later on.

P.S. The issue is also similar for Selection element I guess

Nov 23, 2017 9:19

I'm using Forms 4.8 and go to Admin mode change the Items property to localized. I tried to submit some different values from different languages, but do not got the error  "Unexpected value is not accepted.". Could you please check again? If the issue is still there, could you describle steps to reproduce in details, so I can look at it deeper.


Nov 23, 2017 10:56

We are running Forms 4.6

I was able to reproduce it in following way:

  1. Create Form container block and add it to content area on some page in Finnish
  2. Add to the "Form elements":
    1. Text element
    2. Multiple or single choice element and configure:
      1. Validators: Required
      2. Items:
        1. Choice: Optio 1 ; Value: Option1 FI ; Checked by default
        2. Choice: Optio 2 ; Value: Option2 FI
    3. Submit button element
  3. With Languages gadget create English version with "Duplicate Finnish content"
  4. Go to each form element on English version and translate
  5. Configure Multiple or single choice element:
    1. Validators: Required
    2. Items (it is set in admin to be Localized):
      1. Choice: Option 1 ; Value: Option1 EN ; Checked by default
      2. Choice: Option 2 ; Value: Option2 EN
  6. Go to Finnish page and submit form. It works
  7. Go to English page and submit form. Error "Unexpected value is not accepted."
  8. After changing English values to same as on Finnish site Option1 EN -> Option1 FI and Option2 EN -> Option2 FI submitting works on both languages
Edited, Nov 23, 2017 12:35

Hi, I created a bug AFORM-1445 for investigation to fix. To workaround, you can make Forms work in non-js mode, it will run valid validation process.

Edited, Nov 27, 2017 4:48


I understand you were able to reproduce the issue as well right?

It seems that in non-js mode it is not giving an error, but anyway it looks as a bug.

We will be probably anyway forced to switch to non-js mode and the reason is that we would like to completely rewrite the views and also use Parsley js validation library to do all the client validations (to make it consistent with other static forms) and in js mode we were not able to trigger Parsley validator to validate page on form submit (it was validating when you have changed value in field).

So the question is if there is a way to replace epi forms client validation but still be able to submit form with Ajax (after switching to non-js it makes redirects which is sometimes a problem)

Nov 29, 2017 14:25

And one more thing in non-js mode is there a way to show validation summary with all errors without need to rewrite the FormContainerBlock view?

Nov 29, 2017 15:05

yes, I am able to reproduce the bug. The message  "Unexpected value is not accepted." is from server side validation (SelfValidate  method) when we submit form by ajax. So if you replace client validation, the error is still there. You also need to rewrite the FormContainerBlock view in case you want to display validation summary with all errors.

In order to have "Multiple or single choice" element with localized, I think the easiest way is to create a custom element which inherit from SelectionElementBlockBase<TModel>. Then you override the method SelfValidate to validate yourself with pre-defined localized items.

Nov 30, 2017 3:44

Hi, but is there a way to stay in JS mode still (Ajax submit) but only remove all Epi client-side validations? (we are utilizing Parsley validations)

We realized we have more customizations after submitting the form so switching to non-js mode is not perfect solution for us (also reloading the page and forcing user to scroll to form again is not so friendly solution)

Dec 04, 2017 9:53

Yes, the creating custom element which I mentioned above will keep you stay in JS mode, you just need to override SelfValidate method to vaildate your data with pre-defined values.

Dec 04, 2017 9:59

But you are talking about the server SelfValidate, let's forget for a moment about original problem with "Multiple or single choice" element and only concentrate on a target that for all the epi forms we have we don't want to have default client epi validation but instead use our own validation with Parsley, but still post the data with Ajax as it is in JS-mode. I have seen examples how to add custom validation method but is there a way to remove default epi client validation totally?

So in a short sentence target is: stay in JS-mode but turn off epi client validation (we use Parsley validators). Is there a way to achieve that?

Dec 04, 2017 10:07

If you do not choose validator for your elements, it will be skip validating data with our build-in validators. Is that what you want?


I mentioned about SelfValidate because when the data sent to server, it will be validated again in C#. And in your case, the "Multiple or single choice" get failed, that why you need to create your own custom element.

Dec 04, 2017 10:17

In short words example:

  • We are creating our own epi form element which is simply our custom class inheriting from TextboxElementBlock,
  • we are creating our own view where we setup proper data attributes for Parsley validator (view based on default epi view)
  • we want to send form with Ajax but with Parsley validating the form
  • we do not want the default CLIENT validation for epi forms to be triggered
Dec 04, 2017 10:24

It should NOT validate anything in this case. Is that not working?

Edited, Dec 04, 2017 10:32

Well it looks that standard Epiforms client validation is triggered. I see that it is not called anymore when I remove surrounding wrapper element (e.g. based on extension of TextboxElementBlock)

@using (Html.BeginElement(Model, new { @class = "FormTextbox", data_f_type = "textbox" }))

But after that data is not collected properly when submitting.

Is there some other way to "turn off" epi client validation but still be sure that data is sent on submit?

Note: we are not customizing (yet) FormContainerBlock view

Dec 06, 2017 13:24

Forms does not collect your data because your element is lacking of css class or "data-f-datainput" attribute on the text box. Please see samples here: to know how to create a custom element.

Dec 07, 2017 6:53

I did have already data-f-datainput="" on my input field, but now when I added additional attribute data-f-type="custom" data is submitted

Dec 07, 2017 10:06


I have also experienced this issue today, after first localizing input strings and then inserting values in another language. I have not been able to resolve it with the above hacks and workarounds, and frankly I would expect something like this to work without this hassle.

Can I expect that this issue is worked on and hopefully resolved in a future update of Forms? 


Dec 22, 2017 14:26

Yes, we have the bug and it should be fix on Forms 4.9.1.

Dec 25, 2017 3:31

Great news! Thank you.

Dec 26, 2017 21:03

I have also noticed that the same error message appear when using the time picker on the DateTimeElementBlock, seemingly regardless of the language. If this element is part of the form it will not let you submit.

Hopefully the mentioned fix on Forms 4.9.1 will address this issue as well.

Jan 03, 2018 10:30
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.