Option to ignore keys in JSON/YAML

[infotexture]

Check for existing issues

• Completed

Describe the feature

I'd like to run Vale on the JSON files that contain the UI text for a web app.

If I pass the files to Vale it works, but returns lots of false positives because the string IDs in the keys don't follow the rules (and don't need to), so I'm looking for a way to ignore the keys in each "key": "value" pair, and only run on the values.

These files store strings in i18next’s nested JSON format, so there are multiple levels like this:

{
  "level1": {
    "level2": {
      "stringOnLevel3": "Modal dialog title",
      "nestedObjectOnLevel3": {
        "level4": {
          "stringOnLevel5": "Body text in the dialog with a nasty tttypo.",
          "nestedObjectOnLevel5": {
            "saveStringOnLevel6": "Save",
            "cancelStringOnLevel6": "Cancel"
          }
        }
      }
    }
  }
}

I realize I can add the keys to a vocabulary’s accept.txt file to avoid the false positives and make sure any new keys get reviewed, but that could be a bit fiddly and extra work to maintain.

Given that this use case is similar to the challenges in linting OpenAPI files, I'm wondering whether a more generic approach would be useful, so you would have a way to tell Vale to ignore (or skip) all keys (or all values) and run on the rest of the file without having to script a mechanism to extract the text you want to lint.

Perhaps the Scoping mechanism could be extended, so you could do something like this in the config file:

[*.{json,yaml,yml}]
SkippedScopes = keys

or like this:

[*.{json,yaml,yml}]
IgnoreKeys = YES

[jdkato]

This has been requested many times (#911, for example).

My response has been that I see this as being out of scope for Vale. It's a fundamentally different task than the existing scoping system is designed to handle.

It's more about having a semantic understanding of the format than a structural one, as there's no consistent scopes.

Some want to just ignore keys, while others want to only lint values associated with certain keys. In both cases, the content may contain embedded markup.

#769 is the issue to watch here. I'm not exactly sure of the route that is going take, but it will hopefully help in cases like this.

[infotexture]

This has been requested many times

Apologies for overlooking those. 🙇 (I did try searching for related issues, but apparently not with the right terms.)

The use cases in issues like #383 and #412 are indeed quite similar, so it certainly seems to be a common request.

Glad to hear it's on the radar, will keep an eye on #769.

Thanks for your work here. 🙏