Hello everybody
We would appreciate your help.
We have created a survey form which includes a province based choice of unique-identification-codes of about 1000 survey areas. This uic is seperated by underscores such as "AB_ZY_##########_###’ their label is exactly the same.
If I try it in online-preview and online-datacollection everything works well. If I load the survey to kobo-collect I lose the first 4 underscores and only the last one remains persitent, logically no data is found in the attached csv-file.
Does anyone have a workarround or explanation would we could do or did wrong in setting up our xls-form to avoid this error?
I reply to my owm post, because even here two underscores have been eliminated in my example UIC. so I post this again semantically AB[underscore]ZY[underscore]###[underscore]##[underscore]####[underscore]###.
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
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.
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.
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.
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 XLSForm Reference Table, 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.
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.
Especially, when schedules become tight…
