As far as I understand the problem is not the style of the forms GUI but how Kobo/Enketo whoever treats the VALUE of an Input field.
The input should never ever be automatically processed at all, neither if it is taken from a dropdown list nor if it is a single line input.
Markdown is cool for end user display, but when it comes to capture data… not so…
It is not the input, it is the markdown (formatting element) of the label, e.g. a choice.
Other users use markdowns for example to hightlight something in a label (note, variable, choice item).
In this case a form may offer a dropdownlist of entries, that have underscores in them, that are never processed as markdown in the documents of the organisation but even are used as delimiters for categorisation and data hierarchy…
Something like “AA[Underscore]BB[Underscore]001_34666_meh” etc
The form should show that “Something” as is in Collect(as it actually does in the browser).
And of course we talk abou values, not the GUI design of the form, where Markdown is in fact welcome.
Hrello Wroos
Thank you for any hints, you have given so far. As you saw even our programmer has enganged in this discussion.
I think, as I follow the discussion, that you might not have really understood the problem.
In the net it is stated that ODK (which worked fine , even with our our UIC-design) is dead and that you have either to pay a not really identifiable of Post-ODK developpers if you seek for solutions or you migrate to Kobo. What I want to say that we have setup a REAL-LIFE-workflow for our african surveyors that worked fine with odk-aggregate. Due to the death of these developper we migrated to Kobo and have to learn that the KoboCollect-App (on phone or tablet) does not work as promised by any of the preview or online-collect features. THIS is ARMAGEDON for our platform which connects multiple databases fron GIS to Maria-DB and other Platform-elements.
So we beg you nto explain in 5 sentences, how to mask the underscores so they stay persistant in KOBOCollect. I asure you as zettberlin already did, we did not use any markup or styling elements.
But to be honest, this performance is more than weak, watever the cause may be. cvhanging user definitions of any kind, because the programmers use thirdparty environments (like enketo) without (sorry it seems to be like this) checking real world scenarios seems more than negligent.
We have some 70 surveyors in the field who wait ddesperatly for a solutiuon.
Sorry for the harsh words, but that might enhance even your and the developpers willingness to find a way to get this to work instead citing literature to read. Or at leats state a date in the very near future when this dicscrepance between online tools and kobocollect app will be cleared.
Again, we did not do any markup to any element in our survey-form, but the functionality has been killed by some internal bug which we cannot change, explain to our fiewld-worker or even understand with our tecnical knowledge ( we do this already for some 10 to 20m years).
Sincerely in hope to find practical (real-life) solutions within 2 to 3 days
Dirk
I am sorry, I am a forum user, neither core team or KoboToolbox developper.
I would like to ask @Kal_Lam or @jnm take over here, please…
It might facilitate support from the community if you stay in the same thread for one issue, please. We have already 2 now for your underscore issue.
Sorry, @sieben, I don’t think this is a good style for this community and to motivate any developper. See the the Community Guidelines, please.
Thanks a lot for the hint to use ODK Collect!
We will look into this and see, if it solves that trouble with the broken values!
I am afraid ODK Collect also works with markdowns in labels, see ODK doc link above.
@zettberlin, if you are comfortable, feel free to share your dummy CSV file. Maybe the community should be able to help you out.
Thanks, @wroos. Your support to the community is much appreciated!
@zettberlin, @sieben, if you’re able to share your XLSForm and the associated CSV file as mentioned by @Kal_Lam, we may be able to help further.
We do not apply Markdown formatting to input values.
No argument there. We do not alter the input. You need to understand, however, that choices “taken from a dropdown list” have both labels and values (called name in the XLSForm). Labels can have Markdown formatting applied. Values cannot. I will post a separate message with an example of this to separate it from the clutter.
Sure, and this forum is one venue where it makes sense to allow Markdown formatting. If you need to bypass that formatting when composing messages here, the simplest option is to enclose your text within two backticks. For example, `AB_ZY_###_##_####_###` renders as AB_ZY_###_##_####_### instead of AB_ZY_#########_###. This works only for a single line. If you need multiple lines, please consult a Markdown reference guide.
Let’s suppose you have this XLSForm. On the survey sheet, you have:
| name | type | label |
|---|---|---|
| outside_inside_outside | select_one underscores | outside_inside_outside |
On the choices sheet, you have:
| list name | name | label |
|---|---|---|
| underscores | AB_ZY_111_22_3333_444 |
AB_ZY_111_22_3333_444 |
| underscores | AB_ZY_555_66_7777_888 |
AB_ZY_555_66_7777_888 |
One source of confusion is that if you preview the form, which uses Enketo, you’ll not see any underscores removed from the choice labels. You will see that the question label has had its _inside_ portion changed to inside (italicized). It’s possible that the Enketo developers decided not to enable Markdown parsing for choice labels.
However, if you open the same form in KoboCollect, you’ll see that even the choice labels have had Markdown formatting applied:
Now—where you folks, @sieben and @zettberlin, are mistaken—the crucial part is that the VALUE (again, the name in the XLSForm choices sheet) NEVER has Markdown formatting applied. When I choose the second option and upload the submission, I can clearly see on KoboToolbox that the value is passed through INTACT AND UNTOUCHED by Markdown formatting, with all underscores present:
A note on civility…. I agree entirely with @wroos:
In fact, if he had not already made so much effort to help you (on a strictly volunteer basis!) and if I didn’t think this discussion would benefit others in the community, I simply would not have responded to such language.
Who could tell this? Any reason?
Would be great if the core team could add this difference to the documentation, please. Or - even better - to remove this difference (and others) between Enketo and Collect.
It’s only question labels and hints:
That matches the wording (more or less) of the 2015 blog post describing Markdown in Enketo. Based on that post, support for Markdown in ODK Collect came later (and as we see was implemented somewhat differently).
That would be ideal, of course. Unfortunately, it’s not likely to happen. Beyond choices made by the developers of Enketo and ODK Collect, these are tools for entirely different platforms, written in different programming languages, where entirely different Markdown parsing libraries are available. Even if the parsers were identical, which they are not, the formatting may appear differently due to differences between in-browser rendering vs. native Android applications. There’s just no substitute for testing real forms individually in every venue where they will be used.
Because differences like this are going to remain, and they’ll be difficult to detect until they’re encountered in the real world, perhaps we could maintain a wiki post somewhere on this forum where we could collaboratively catalog them. @Kal_Lam and @Josh, what do you think of that idea? Alternatively, we could try to facilitate contributions to Reference and Template, maybe providing some way to suggest changes without needing a GitHub account.
A word on @sieben and his early posts.
Please do not take offence. He wrote that in a situation of despair: our project is for environmental protection efforts in Northwest Africa, we promised the staff to make their work easier and we get very nervous if it looks like we cant 
Especially, when schedules become tight…
We are very thankful for your help and I’d like to express my thanks to @wroos for the patience.
Your hints here have given us new hope 
I completely aggree on the “make enketo and the apps act the same as much as possible”.
We have a workflow, where staff collects data in the field with the app and senior staff and experts review and correct if needed in the browser with Enketo…
I guess, thats what many projects do and it works much better for us overall than it did with aggregate.
I shared the relevant code in the other post, here again:
This would be the form:
<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>
and here the CSV:
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
@sieben told me, that there could be a problem with connecting the CSV file when importing the form in Kobo Collect…
We cannot share the whole files since they contain data we are not allowed to share in public…
Sorry, those time management problems should better not be forwarded to the community, where many people do voluntary work for African colleagues/projects too.
Could you meanwhile try out this workaround?
Would this look exactly the same in Enketo and Collect?
No, it will not. The backslashes will show up in Enketo, because Enketo doesn’t do Markdown processing on choice labels. The values, however, will be the same (and correct) on both Enketo and Collect.
Cross reference:
