The Ubiquitous Language is not so much a design artifact, like a class diagram, as it is a discovery by conversation — a process. If done right, the Ubiquitous Language is not a document. It is a consideration you take when naming something significant in the software system. It permeates all other documents by the names that things and processes are given. The software system itself becomes the documentation of the Ubiquitous Language, because classes, methods, variables, packages, diagrams and test cases all include this language.
This is where Behavior Driven Development pairs well with Domain Driven Design, because properly written behavior driven tests use the Ubiquitous Language. BDD tests should use the same terms and phrasing to describe the application behavior that is utilized by real end users to describe their business processes. So BDD tests written in Gherkin can be yet another reinforcement of the Ubiquitous Language.
Nearly every artifact of the software system, from the requirements, to use case diagrams, class diagrams, to code, should use the same Ubiquitous Language.
To be clear, a simple "ubiquitous language dictionary" is not enough. A dictionary of terms is good to have, but I can tell you from experience that people tend to forget where this dictionary is, and so it goes unused. You spend most of your time e-mailing teammates a link to this document.
There is no official "Ubiquitous Language Document". Remember the important part of Ubiquitous Language is the "ubiquitous" part:
Existing or being everywhere, especially at the same time; omnipresent: ubiquitous fog; ubiquitous little ants.
If you need a reference document of terms, create one. Keep it simple. Word document, wiki, doesn't matter. Point other people to it, and know that you will continually do so until the end of the project. The Ubiquitous Language should be everywhere to begin with from requirements to documentation to code. To understand even a single use case is to begin understanding the Ubiquitous Language.