WIP: add vale rules for wording

[christinaausley]

Description

Adds Vale linting warnings for non-inclusive language and terms to avoid. Closes #1904.

When should this change go live?

• This is a bug fix, security concern, or something that needs urgent release support.
• This is already available but undocumented and should be released within a week.
• This on a specific schedule and the assignee will coordinate a release with the DevEx team. (apply hold label or convert to draft PR)
• This is part of a scheduled alpha or minor. (apply alpha or minor label)
• There is no urgency with this change and can be released at any time.

PR Checklist

• My changes are for an already released minor and are in /versioned_docs directory.
• My changes are for the next minor and are in /docs directory (aka /next/).

• My changes require an Engineering review, and I've assigned the Engineering DRI or delegate.
• My changes require a technical writer review, and I've assigned @camunda/tech-writers as a reviewer.

[christinaausley]

@pepopowitz Mind taking a peek to see if I have outlined and placed these properly? I'll loop in the tech writers for final review.

[pepopowitz]

I think I sent you down the incorrect path, with these rules, I'm sorry!

I also would like to see some proof of what it looks like in GitHub when these rules are violated. That could be commits added in this PR, the review comments screenshotted, and then the commits rolled back....or it could be another PR opened against this branch, and linked to from here.

Let me know if I can help!

[pepopowitz]

Should these apply to the Optimize docs as well? Adding them to the styles/camunda/docsInstance folder means they'll only apply to the main docs instance.

I think you want to move them to the styles/camunda/all folder instead, so that they apply to both the main docs instance and the Optimize instance.

[pepopowitz]

Unfortunately I can't find anything in the vale docs that explains this very well, but I now realize that I suggested the wrong base rule for these.

If you look at the example here, it extends "substitution" rather than "existence", and defines a "swap" array instead of "tokens". In doing so, it enables the linter to provide a suggestion for the correct value. I think that would give us more actionable feedback in the PR review comments, particularly a commit-able suggestion for the alternative.

I'm a little bit guessing at that, though. We would know for sure if you added some changes to this PR, or opened a PR into this PR with violations.

[christinaausley]

I see what you're suggesting here @pepopowitz -- WDYT of the updates?

[pepopowitz]

Yes, exactly! These look great, except two replacements that I think were overlooked.

[christinaausley]

@camunda/tech-writers Are there any additional terms you would like to add here? I'm trying to keep the first iteration pretty minimal, but if I'm missing something that would be helpful please let me know and I can add to this PR before merging 👍

[akeller]

Can we add "docker compose", as in the command (all lowercase)?

[akeller]

Or if that's written intentionally in code, as a terminal command, will this get flagged?

[christinaausley]

This will get flagged -- similar to my lack of "javascript" currently. There are a few threads online discussing how we can ignore code blocks, but I may open this as a subsequent issue so I can do some research and testing on what that looks like?