You are correct that building a rich and descriptive vocabulary for your domain is crucial for efficient communication. However, as mentioned in the comments, the reality is that, even in the same industry/domain, the actual terminology used will vary from company to company.
Domain Driven Design has a concept called Ubiquitous Language that kind of deals with this.
In an effort to simplify communication between the technical team and the domain experts, DDD recommends everyone involved on the project use the same language to when talking about the domain. For example, if the end-user calls it a
doodad then it's a
doodad when we speak about it, and it's a
doodad when we code about it. Keeping the terminology the same everywhere (even in code) eliminates the need for translating terms between contexts and helps keep communication easy.
And, since we're typically building software for people who already have a natural way of speaking about their domain, it usually makes sense to use that as a starting point for your ubiquitous language (UL).
It is possible for the technical team to ask for refinements of the UL, but for the most part it is a domain-expert/end-user driven glossary of terms.
So, you can kind of dodge the problem of learning "industry-standard" terminology as long as you focus on using Ubiquitous Language.