Fix unintended highlighting of certain glossary terms

[httphypixelnet]

Description

This PR aims to close #98 and create a framework for content authors to add glossary terms without worrying about them colliding with unrelated words (eg: CAN vs can). It also fixes certain type issues and enforces Typescript best practices.

Closes #98

Meta

Merge checklist:

• Pull Request title is short, imperative summary of proposed changes
• The description documents the what and why, including events that led to this PR
• Pull Request has been linted and formatted and follows the styleguide

[samfreund]

Prefer going by case. When CAN is meant to be referenced as the glossary item, we expect it to be capitalized. This should be sufficient for all other terms as well.

Additionally, various ts fixes should be a separate PR (they're free).

[httphypixelnet]

Prefer going by case

So instead of an autoDetect, we have two RegEx to match case-sensitive and case-insensitive terms?

Additionally, various ts fixes should be a separate PR (they're free).

Got it.

[samfreund]

Prefer going by case

So instead of an autoDetect, we have two RegEx to match case-sensitive and case-insensitive terms?

I would say the simplest option is to check if the word in the glossary is lowercase, is so match any case. If it's mixed case/upper (proper noun), match only specifics. Having people label case-(in)sensitivity would also work, design decision tbh.

[httphypixelnet]

If it's mixed case/upper (proper noun), match only specifics

All of the terms in the glossary as of now are mixed case (and I can't imagine there will be a place where something like "Magnetic Encoder" will not be the same magnetic encoder as the glossary term).

[samfreund]

If it's mixed case/upper (proper noun), match only specifics

All of the terms in the glossary as of now are mixed case (and I can't imagine there will be a place where something like "Magnetic Encoder" will not be the same magnetic encoder as the glossary term).

Yeah, you'd want to convert those to lowercase. As I said though, it's up to you which approach you want to take.

[httphypixelnet]

I'm gonna go with the current approach until we find a use-case that makes it worse than the other approach

[httphypixelnet]

(ready for review)

[github-actions]

🌐 Preview URL: https://pr-103.frcsoftware.pages.dev

[httphypixelnet]

hmmmm, I think the boundaries are incorrect on these. fixing

[samfreund]

Requiring people to wrap in a glossary block is a lot of overhead. I'd prefer if we add an option to the glossary to make terms case-sensitive, rather than requiring wrapping.

[httphypixelnet]

As I said though, it's up to you which approach you want to take.

💀 you told me it was up to me, and then blocked the merge because I didn't design it how you wanted?

[samfreund]

As I said though, it's up to you which approach you want to take.

💀 you told me it was up to me, and then blocked the merge because I didn't design it how you wanted?

My understanding was that it would be case-sensitive regardless, and not require wrapping in a glossary block. The first approach would've used mixed case for terms that will be sensitive in the glossary, and the second approach would have a Boolean indicator of whether it should be case-sensitive. If that wasn't clear, I apologize.