The code:

			'dir' => array( "In which direction to enumerate}",
				" newer          - List oldest first. Note: {$p}from has to be before {$p}to.",
				" older          - List newest first (default). Note: {$p}from has to be later than {$p}to." ),

Probably just copied from somewhere else...

So logevents has these:

	"apihelp-query+logevents-param-start": "The timestamp to start enumerating from.",
	"apihelp-query+logevents-param-end": "The timestamp to end enumerating.",

And checkuserlog these:

			'from'   => 'The timestamp to start enumerating from',
			'to'     => 'The timestamp to end enumerating',

Basically, culfrom is like lestart and culto is like leend? Should we just alias start/end -> from/to for consistency in checkuserlog?

In T113205#2006019, @Krenair wrote:

The code:

			'dir' => array( "In which direction to enumerate}",
				" newer          - List oldest first. Note: {$p}from has to be before {$p}to.",
				" older          - List newest first (default). Note: {$p}from has to be later than {$p}to." ),

Probably just copied from somewhere else...

Note that getParamDescription() that you quoted that code from is deprecated since 1.25.

Unable to work out how to alias it without having two different ways to put the start / end in on Special:ApiSandbox.

Change 806412 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/CheckUser@master] Use to and from in culdir api help message instead of start and end

https://gerrit.wikimedia.org/r/806412

Change 806412 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Use to and from in culdir api help message instead of start and end

https://gerrit.wikimedia.org/r/806412

Resolving this task as it addresses the issue of incorrect API documentation. Standardisation to culstart and culend is definitely a good idea, but without changes to core it seems that aliasing parameters (i.e. allowing both culstart and culfrom) is not possible. Removal of the culfrom parameter is major enough that standardisation is not important enough to warrant the breaking changes.