I'll contribute something I noticed, as a native English speaker, when I started defaulting to too-terse in my own style: Instead of spending time worrying about how to capture enough meaning in a concise name, I can write "km", write a comment beside the declaration like "keyboard mapping", and I'm done. The symbol-meaning is mnemonic, the documentation is verbose.
Or to consider it another way, we've constructed the idea of variable naming being essential under the premise that we want code to relate to native language at each step. But when code is put into an interlingual context this breaks down relatively quickly - at the extreme end, the non-native speaker has to reverse-engineer meanings anyway. In the terse/documented style, I more explicitly acknowledge this separation of actions and definitions.
A lot of the thinking around naming conventions feeds into the expected workflow - when considering the pre-Intellisense, namespace-free era of C coding that Windows Hungarian arose in, it makes sense to bulk up the names a little so that every point of the code conveys more meaning and doesn't collide by accident. But if the environment already gives you ample guidance towards meaning and categorization, the bottleneck revolves more around how much code fits onscreen.