Wrong replacement of "complies" (v. comply) with "compiles" (v. compile)

[akien-mga]

Seen while testing e47c98c on the https://github.com/godotengine/godot codebase:

diff --git a/doc/classes/EditorPaths.xml b/doc/classes/EditorPaths.xml
index c4d4c92afe..afd55d15f3 100644
--- a/doc/classes/EditorPaths.xml
+++ b/doc/classes/EditorPaths.xml
@@ -6,7 +6,7 @@
	<description>
		This editor-only singleton returns OS-specific paths to various data folders and files. It can be used in editor plugins to ensure files are saved in the correct location on each operating system.
		[b]Note:[/b] This singleton is not accessible in exported projects. Attempting to access it in an exported project will result in a script error as the singleton won't be declared. To prevent script errors in exported projects, use [method Engine.has_singleton] to check whether the singleton is available before using it.
-		[b]Note:[/b] Godot complies with the [url=https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html]XDG Base Directory Specification[/url] on [i]all[/i] platforms. You can override environment variables following the specification to change the editor and project data paths.
+		[b]Note:[/b] Godot compiles with the [url=https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html]XDG Base Directory Specification[/url] on [i]all[/i] platforms. You can override environment variables following the specification to change the editor and project data paths.
	</description>
	<tutorials>
		<link title="File paths in Godot projects">https://docs.godotengine.org/en/latest/tutorials/io/data_paths.html</link>

While it's true that "compiles" is probably more common than "complies" in codebases, the verb "comply" is still commonly used when talking about specifications. Maybe this hit should be downgraded to a hint of potential typo instead of an autofix one?

[luzpaz]

Yes, I wish we had a dictionary that has these types of terms but isn't utilized by default when running codespell.

[luzpaz]

@peternewman I've encountered the false positive more than actual hits. But I still think this is valid. But it doesn't belong in code dictionary. Thoughts?

[peternewman]

So this is the same issue as #2281 .

I'd prefer not to put them in the main code dictionary, as currently all the "typos" in there are invalid dictionary words, so we can validate that the typo doesn't exist in the dictionary at least.

We talked about splitting rare into rare and really rare, depending on whether the typo exists in the core aspell dictionaries or something, and hence how likely the typo is to be the intended word, but these would still match that (so maybe a new dictionary like that should be disabled by default as there's a good chance you actually meant the typo, compared to the more obscure stuff in the really rare dictionary).

Although I guess the difference is in a code context, there's a good chance crate is what you meant (for rust at least), whereas for this, most people probably mean compiles in a code context. i.e. whether you want the typo in the dictionary or not is opposite for the two.

Perhaps the better way to think is because they're "popular" rare words, we can be less confident that they're actually typos and so the dictionary shouldn't be enabled by default (for corrections at least, but possibly generally).

[vikivivi]

Also see valid word complies in Apache License.
https://www.apache.org/licenses/LICENSE-2.0
distribution of the Work otherwise complies with the conditions stated in this License.

[TheMostDiligent]

Today codespell check started complaining about the complies in the license files.

[sunjayBhatia]

same here on the Apache License

the suggestion to stop using the "rare" dictionary should work, but it seems like it should also be removed from the default dictionaries for general usability

[peternewman]

whereas for this, most people probably mean compiles in a code context. i.e. whether you want the typo in the dictionary or not is opposite for the two.

Okay so clearly the licence thing blows my comment above out of the water regarding code.

Which leaves us with:

We talked about splitting rare into rare and really rare, depending on whether the typo exists in the core aspell dictionaries or something, and hence how likely the typo is to be the intended word, but these would still match that (so maybe a new dictionary like that should be disabled by default as there's a good chance you actually meant the typo, compared to the more obscure stuff in the really rare dictionary).

Perhaps the better way to think is because they're "popular" rare words, we can be less confident that they're actually typos and so the dictionary shouldn't be enabled by default (for corrections at least, but possibly generally).

Suggestions very much welcome for names and descriptions for the two rare dictionaries. Running the split along aspell dictionary lines seems like the obvious thing as it makes the CI easy to implement and manage what lives in each (although I guess ideally a more restricted/core aspell dictionary than we might want for corrections.

[TheMostDiligent]

I honestly think that suggesting to replace one legitimate word with another without analyzing the context is not correct.

[vikivivi]

Suggestions very much welcome for names and descriptions for the two rare dictionaries.

My 1st suggestion.
Simply rename rare dictionary to likely and disable it by default.

My 2nd suggestion in plain English description
likely1: valid words that are likely to be errors (default: enabled)
likely2: valid words that are likely to be errors (default: disabled)

My 3rd suggestion in plain English description
likely: valid words that are likely to be errors (default: enabled)
plausible: valid words that seems likely to be errors (default: disabled)

[akien-mga]

I'm not well versed into how dictionaries are setup but if the problem we're all having is just with complies/compiles replacement, and nobody claims that this replacement has been useful to them, I'd suggest just removing it.

I don't see a need for disabling other useful replacements by defaults just because one of them is often faulty. The faulty one should just be removed (or can be moved to a dedicated dictionary disabled by default, but it should be one specifically with well known potential false positives).