Validation on task description not helpful when using Mustache Tag Replacement

[tordans]

For https://maproulette.org/challenge/45242/task/227680961 I am using Mustache Tag Replacement to provide the description of the task from my GeoJSON (Example).

Each Feature in my geojson has a task_markdown property which I generate to have custom information per task (Code).

The min-char validations prevents me from saving the description with just the Mustache Tag {{task_markdown}}. I have to add some characters to the description just to get around the validation.

Possible solution:

• Make the validation a warning only, but don't prevent saving the challenge
• Remove the validation once mustache tag replacements are present in the text
• …?

[mvexel]

Only the Mapillary links are different in your example -- could you just reduce the redundancy by making the rest of the text static?

[tordans]

could you just reduce the redundancy by making the rest of the text static?

In this specific case yes. I would consider that a workaround. But I can also work around the issue by adding blank text to the text field.

I have other campaigns where the whole descriptions changes based on context data that I have available in the application where I create the Challenge-Dataset. For example, I can add/remove suggested solutions for an issue based on other OSM data I have.

My general goal is to have a workflow where I can craft and control the whole dataset in our application so we don't need to switch tools too much.

[mvexel]

Since mustache tags are an uncommon use case, perhaps we can disable the string length requirement for instructions that contain them?

Alternatively we don't make it a hard requirement but we encourage the user to keep writing, like displaying a warning if the instructions are very short like JOSM does

Thoughts?

[tordans]

Thoughts?

From a user point of view both solutions work well.

Another (much) more hacky workaround would be to count white spaces towards the required characters but strip them before returning the data from the API / before displaying the comment. That would allow to document a workaround for those using this kind of setup without polluting the UI with non helpful characters.