Rather than a implementing a new message (if that's what we want to do), I think it would be better to add a JSON config like we talked about.

I took some time to look into JsonConfig extension and whether it will suit our needs. The documentation recommended a single configuration object per extension, and I think that is a good recommendation for us to follow.

Pros

• Default We can still provide a default configuration object that will be used by all wikis unless they explicitly override it. When they override it, the editor will be presented with the default in JSON format so they can edit the existing config. We could add the default config to a MediaWiki config variable so it can be set in LocalSettings.php rather than having to create a wikipage to override it.
• Validation We could come up with our own message format and give instructions on how to edit it and what we expect, but ultimately there isn't anything that validates that it's in the format we expect it to be in (we'd have to write that ourselves). JsonConfig provides a mechanism to validate that the configuration is in the shape we expect it, and if it's not, will not allow the config to be saved (and presents a helpful error message). This means we can be confident that the configuration object is in a valid format, regardless of how it's been overridden.
• Internationalization While having a message would allow us to have custom tools for each wiki, it doesn't allow us to have translated labels on a wiki, which becomes necessary on multilingual wikis like Wikidata and Commons. I noticed that there isn't a way in MediaWiki (that I could find) for contributors to define new translation keys, they can only override existing ones. With JsonConfig we could either accept an existing message key (which would be the default), or JsonConfig can expect a localized map in the form of { en: 'Hello', es: 'Hola' }. This way, contributors can express the translations for the label in the config itself (since they can't create new message keys).

Cons

• (Optional) Dependency This would create an optional(?) dependency on JsonConfig. The documentation for the extension implies that it must be a required dependency, but in my testing this wasn't necessary (as long as we check to ensure the extension is loaded before using any of it's methods). This shouldn't be a problem for Wikimedia because it appears the extension is enabled on all of our wikis. However, if a wiki doesn't enable the extension, the only way to override the configuration will be in LocalSettings.php.
• Config Namespace While the extension is enabled on all of Wikimedia's wikis, it doesn't look like a single extension uses it for "local" configuration other than Meta. The extension is also used on Commons, but it is used for GeoJson and Tabular JSON data rather than configuration. This means that if we start using the extension for configuration a new Config and Config_talk namespaces will be registered on all of Wikimedia's wikis (other than Meta, where it already exists). This will be an empty namespace unless the wiki overrides the CheckUser configuration. The wiki may need to protect the namespace or protect the Config:CheckUser page from being created (which will override the configuration). Alternatively they could create the page and then protect it. We should set wgNamespaceProtection on Wikimedia's wikis to the same configuration as NS_MEDIAWIKI. I don't imagine this will be a problem, but we'll need to communicate to the wikis that this is happening. On the plus side, once we open up the namespace, that will allow other extensions to start using the namespace without having to do this.

Overall, I think this is the best direction, I'll create a task to implement the changes in CheckUser.