OpenBeta
Boulder grades are not case sensitive
.toUpperCase required on boulder grades so entries where the grade is entered v3 will show V3 in front-end.
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 https://github.com/OpenBeta/sandbag/issues/177, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD7ET7FI4DFU3OOVCZ4V2CDZ7OGSDAVCNFSM6AAAAABRLSD7F6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRSGY2DANJUGI . You are receiving this because you are subscribed to this thread.Message ID: @.***>
@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
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 https://github.com/OpenBeta/sandbag/issues/177, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD7ET7EXIW7ZK74JVYZ56MTZ7O375AVCNFSM6AAAAABRLSD7F6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRTGAZDOMBWHE . You are receiving this because you were mentioned.Message ID: @.***>
Good to know the context of other systems.
It does seem like if it's a boulder one could just uppercase it client side?
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
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?
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.
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.