Fix words with 'reference'

@quietone Looks good
Do we have separate ticket for other words related to reference

Patch #5 applies cleanly on on 9.2.x.

$ yarn spellcheck:core
yarn run v1.22.4
$ cspell "**/*" ".*" "../composer/**/*" "../composer.json"
core/modules/migrate_drupal/src/Plugin/migrate/field/d6/NodeReference.php:11:12 - Unknown word (nodereference)
core/modules/migrate_drupal/src/Plugin/migrate/field/d6/NodeReference.php:14:9 - Unknown word (nodereference)
core/modules/migrate_drupal/src/Plugin/migrate/field/d6/NodeReference.php:16:23 - Unknown word (nodereference)
core/modules/migrate_drupal/tests/src/Unit/Plugin/migrate/field/d6/NodeReferenceFieldTest.php:37:44 - Unknown word (nodereference)
CSpell: Files checked: 15135, Issues found: 4 in 2 files

Fixing.

Looks good to me.

+++ b/core/misc/cspell/dictionary.txt
@@ -120,7 +120,6 @@ backend's
 backlinks
 backport
-backreferences
 backtraces
 bakeware
 bangpow
@@ -521,7 +520,6 @@ enoki

@@ -521,7 +520,6 @@ enoki
 enregistrer
 entit
 entitynodeedit
-entityreference
 entitytype
 entityviewedit
 entrypoint
@@ -1047,7 +1045,6 @@ nocookie

@@ -1047,7 +1045,6 @@ nocookie
 nocssjs
 nodeaccess
 nodelink
-nodereference
 nodo

To be honest I feel like all three of these words are fine to have in the dictionary.

backreference is a real technical term that's in common usage. nodereference and entityreference feel like Drupal neologisms rather than typos (and as the patch shows they're used several times).

If so, this is a won't fix.

Fixed broken list item in the task description.

All but one of the changes here are migrate related and refer to term used in Drupal 6 and/or Drupal 7.

So for me if we're having to cspell: ignore a word in multiple different non-test files then it shows it's a word that we actually use. When we eventually drop support for migrating from Drupal 7, all those usages will be removed, and it'll be an unused word in the dictionary.

+++ b/core/modules/views/src/Plugin/views/query/Sql.php
@@ -337,8 +337,8 @@ public function submitOptionsForm(&$form, FormStateInterface $form_state) {
    * relationship.
    *
-   * An example of a relationship would be a nodereference table.
-   * If you have a nodereference named 'book_parent' which links to a
+   * An example of a relationship would be a node reference table.
+   * If you have a node reference named 'book_parent' which links to a

This is the main usage of nodereference that's outside of migrate, but I wonder if the example itself is outdated now.

Leaving RTBC because I'm not sure what the right approach is here, still getting used to cspell but this is definitely borderline for me.

Based on #9-13 I am leaning towards "won't fix" for this most of this now.

"nodereference" and "entityreference" are Drupalisms and those are OK to have in the dictionary; we will always have some words that are special to this project. In conjunction with #11 I am tempted to suggest we put "userreference" back in the dictionary for consistency.

"backreference" is citable as a real word in the context of regular expressions, so I think this is OK too: https://en.wiktionary.org/wiki/backreference. Alternatively it only appears in two comments and "back reference" is just as understandable, so we could just fix these here?

Won't fix +1, no need to revert userreference to be consistent to me, I think userreference is rarely used in Drupal 8/9.

userreference
entityreferrence
...

I think those are historical legacies and could/should be avoided at the beginning by adding _. They do not have to be Drupalized words. Unlike Druplicon, drush, nid etc, which are true new words in the Drupal land.

how do we identify words in the dictionary that are to stay in the dictionary?

A good question to continue.

My 2 cents: the fewer words stay in the dictionary, the better.

Can we have a section in the dictionary for words that are not to be changed and perhaps the reason?

misc/cspell/dictionary.txt is generated automatically, comments are not allowed AFAIK. #3153919: Rename dictionary.txt file to drupal.dic to make it compatible with PhpStorm on Linux here adopted an approach having two dictionaries, -- adding a permanent dictionary for those words is possible, but ideally, one dictionary is better.

+++ b/core/modules/field/migrations/state/field.migrate_drupal.yml
@@ -1,3 +1,4 @@
+# cspell:ignore entityreference

This shouldn't be needed any more given it's staying in the dictionary.

Rerolled and addressing #18 thanks!

Setting back to RTBC

So I think the ideal thing would be if migrate (or any other component) was able to add it's own dictionary.txt, which would be cumulatively combined with core's - however that's not really a feature of cspell. As it stands, to me it makes sense to keep these in the dictionary, then when the code is removed, they can be removed too. But having to cspell-ignore the same terms, which we're intentionally using, over and over again doesn't seem great.

Committed/pushed to 9.2.x, thanks!