Hello,
Ist it possible to disable Mardown for the value of a form entry in Kobo Collect?
Thing is: we need to collect data with collect that is described by IDs, that use certain chars such as underscore. We do not have the option to ask the organisation to change the format of these IDs: they have to have underscores in it.
Its very very irritating, if staffers try to put such an ID in a text field and see, that it is automagically and unwanted transpormed…
Would you mind to have a look at the posted link (last bullet), please ?
\ character before #, *, _, and \ to prevent special styling effects to be triggered by these characters1I know this doc.
I am not talking about Markdown in the form GUI but in the values of fields
Markdown for the label of an entry is perfectly welcome and not a problem.
We see strange mutations in the VALUES selected from a dropdown list.
@zettberlin, could you share with the community a sample of the issue you are having? Maybe the community could give a try on how to overcome?
Its a select:
All these underscores should be shown as is…
<select1 appearance="minimal" ref="/FORMID/gen/plotID">
<label ref="jr:itext('/FORMID/gen/plotID:label')"/>
<item>
<label>AM_DD_031_30_2200_001</label>
<value>AM_DD_031_30_2200_001</value>
</item>
<item>
<label>AM_DD_031_30_2200_002</label>
<value>AM_DD_031_30_2200_002</value>
</item>
Could you share an extract of your form and a screenshot with problem, please, to facilitate support here.
Did you try the suggestion to use \ to mask the markdown elements? See above.
These ID Numbers are drawn from an CSV, Of course we could hack it with sed to replace Underscores with Backslash Undersore for the labels(because as said before: the values have to have Underscores as is)
but on the other hand some “do not process any markdown in that label” tag would be much easier…
If such a useful tag does not exist, we have a way at least…
Above I wrote, that I would replace Underscores with a sequence of Backslash Underscore, exactly, what you suggested, so thank you.
Here are 2 lines of th csv, all others are the same
uic;woreda;areaname;surf;managname;groupmemb;plantedyr;plotclass
AM_DD_088_19_2029_001;NameofLocation;Area;10620;"Owner
";4;2020;2
AM_DD_088_19_2029_002;Loc;Atat Area;10620;"Owner
";4;2020;2
p.s.: it works absolutely flawless in the Browser…
Would you mind to send an extract of the files, please, directly as files, including the csv and the related parts of the form.?
What was the result when you added the backslash (in the csv), please ?
Another workaround might be to replace the underlines by - in the choice labels (but keep them in the choice names), This will work for Enketo and Collect.
What do you finally want to use? Collect or Enketo (Webform)?
Be aware, please, that in general there are some differences between Enketo (Webform) and Collect (Kobo and ODK) ? These are two different SW applications!
Hi @Kal_Lam: Might be good to add the differences for markdowns and HTML tags to the Enketo / Collect XLSForm Reference Table.
Sorry, but these files contain sensitive Data that we are not allowed to share with the public, hence the edited lines I posted here, that contain every part involved.
It works perfectly with Webforms, only Collect shows the unwanted Behavior…
As we are on it: IF we hack that with Backslashed in a Way, that works with Collect, it would not work in the webform anymore…
Yes, it seems that _ (underline) markdown is not treated by Enketo.
A solution would be to replace the underlines in your labels by - (hyphen) This will work in Collect and Collect.
Respecting data protection, it would be helpful if you can send a screenshot or short form extract to see where and how the csv is used and where the underline issue is relevant. The community may then find other workarounds.
Thanks for your patience. 
I have respective source codes of the form XML and the connected CSV here in posts above.
I will see into that hyphen workaround anyway, that would mean, that the collected data would contain malformed IDs… Maybe we could send some search/replace request via REST?
You could do it in XLSForm: Include a calculate type and use the translate function to replace all hyphens by _. See ODK XForms Specification.
Or you use the \ option and replace this in the same way.
Wiil you use Collect and Enketo in parallel?
Could you provide the relevant extract of the form as XLSForm, please, not the HTML code? I would also like to see how you use the csv in the form.
@zettberlin, you seem to be trying to pull values from the CSV file. The values must have come to your form without issues when you try using the browser but must be an issue when you try using the Collect Android App. Did I get you correct?
