Apply different rules to different paths/files

[guykisel]

Is your feature request related to a problem? Please describe.
Hi, I'm an engineer working on Legends of Runeterra, a video game (https://playruneterra.com/en-us/). We're using woke to clean up problematic terminology in our code to make it more inclusive :) But one problem we have is that we want to filter out terms like "grandfather", but they do sometimes show up in some of our content in a contextually-appropriate way. For example, we have a card in the game named Grandfather Rumul (https://leagueoflegends.fandom.com/wiki/Grandfather_Rumul_(Legends_of_Runeterra)) and we don't want to block commits or break builds for this usage. Currently I'm dealing with this in our .woke.yaml like this:

  # we will error on "grandfathered" but not on "grandfather" because we have a card named "Grandfather Rumul"
  - name: grandfathered
    terms:
      - grandfathered
    alternatives:
      - legacy status
      - legacy
    options:
      word_boundary: true

But this means we might not catch some inappropriate usages of "grandfather" in code. woke does allow for inline ignores, but we have a lot of generated yaml (Unity prefabs - https://docs.unity3d.com/Manual/Prefabs.html) that we can't easily put inline ignores in. We could just ignore all of these generated yaml files, but again that means we might not catch other inappropriately used terms, so it feels like we're a bit stuck.

Describe the solution you'd like
I'm looking for guidance/suggestions of how to deal with this, or perhaps some sort of feature we could contribute to woke that might help with this. Perhaps something like a regex or glob filter field we could add for each term in .woke.yaml so we could apply specific rules to specific filename patterns?

Describe alternatives you've considered

• some complex custom scripts to run woke in several passes using different config files
• leaving some files unscanned/unchecked
• leaving some terms unenforced

Thank you for taking the time to read this!

[cognitivegears]

Wow interesting usage! Not a solution directly, but there is a PR for a change that I think could solve this for you, #117. Unfortunately I think that PR still needs some work, but you might be able to try it out to see if it will work for you in the meantime. Alternatively, my PR #133 for custom regex may also help, though unfortunately Go regex doesn't support look around regexes so the regex would be a little more complex but may be feasible.

[guykisel]

Yeah, I suppose another option could be to have special exclusion rules/allowlisted usages and phrases.