I'm not aware of a canonical book. That may be because design best practices are likely to be domain-specific. A language for mathematicians should look very math-like, a language for chemists should look very chemistry-like, etc. Some things that make no sense in one domain are essential in another.
For example, I write software for networking equipment, which has its own language for configuration. The command for shutting down a port is, intuitively enough,
shutdown. However, the command for enabling a port is
no shutdown. To me, that's the stupidest design ever, but it's very natural for our users from a historical perspective.
Keep in mind, unless you're squarely in the target demographic, you're probably the worst person to design the language. You will tend to want something with an efficient grammar, or easy implementation, or consistency with programming languages you know, but the user doesn't care about those things. Start out by reading something an end user has written, and consider your job to be refinement of that based on criteria like parseability, consistency, and removing ambiguity.
For example, I'm currently working on a language for keeping track of all the numbers associated with pen and paper roleplaying games. Rather than starting with the grammar, or looking at other programming languages I could adapt, I started by looking at how those numbers are described in existing published rule books. They have a lot of phrases like "-2 penalty to armor class when cowering," so that's what my syntax looks like, with words like
when being keywords. There are obviously some restrictions necessary to make it readable by computer, but most of the time a user is going to be able to copy directly from a rule book with only minor modifications.