Boulder grades are not case sensitive

[julianlam]

.toUpperCase required on boulder grades so entries where the grade is entered v3 will show V3 in front-end.

[julianlam]

[musoke]

This is good for font grades too, but are there any other boulder grading systems which are not uppercase?

…

On Thu, Nov 7, 2024, 08:13 Julian Lam ***@***.***> wrote: image.png (view on web) <https://github.com/user-attachments/assets/38d2fc51-e3c0-4dfe-863f-daecaa2e49a6> — Reply to this email directly, view it on GitHub <#177>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD7ET7FI4DFU3OOVCZ4V2CDZ7OGSDAVCNFSM6AAAAABRLSD7F6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRSGY2DANJUGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[CocoisBuggy]

@musoke I don't know of a case-sensitive grading pattern, but I have a similar concern - Luckily this is the sort of front end change that is quick to roll back if someone points out to us the folly of our actions

[musoke]

French sport and boulder grades are conventionally case-sensitive - often the case is the only way of distinguishing them. Uppercase for boulder, lower case for sport.

…

On Thu, Nov 7, 2024, 11:16 Colin Gale ***@***.***> wrote: @musoke <https://github.com/musoke> I don't know of a case-sensitive grading pattern, but I have a similar concern - Luckily this is the sort of front end change that is quick to roll back if someone points out to us the folly of our actions — Reply to this email directly, view it on GitHub <#177>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD7ET7EXIW7ZK74JVYZ56MTZ7O375AVCNFSM6AAAAABRLSD7F6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRTGAZDOMBWHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[julianlam]

Good to know the context of other systems.

It does seem like if it's a boulder one could just uppercase it client side?

[CocoisBuggy]

I think in that case this issue should be transferred over to sandbag, since grade formatting standardization should happen there - in the mean time probably best not to do any heuristic casing since it could confuse future devs

[enapupe]

I could work on this if there's a clear path towards how to standardize this. Perhaps make all grades strict and only accept/output in the expected/correct case?

[CocoisBuggy]

My intuition is that there is anything but a clear path toward standardizing this. Implementation will be trivial once such a path exists, but actually we need some grade nerds to go case by case and create a schema for which grades are case sensitive and which ones are not. Until then I think anything we do might get a little messy.

A little backstory about my feelings here: In the earlier days of openbeta I could not add any climbs because the input fields were too sensitive to take the grade inputs that users needed to see, and I felt a little frustrated that the system could not accommodate a text field that users should be trusted to supply.

[enapupe]

What if we implement a format function that would then be used in the frontend for input formatting? Each grade should implement it's own, for some grades that function would just be a toUpperCase call. Along with that we'd have to perform a "migration" of existing data.