You can treat "ubiquitious language documentation" as a software customization project: you need to take some software for documentation management and adapt it to your specific need. In software projects you normally start with gathering user needs, then you build information architecture and design solution and then you proceed to implementation. Below is the example of this process.
What are the user needs for it? In some organization people with different functions from different domains want to use common language dialect for describing their problems and solutions. This dialect will be defined solely by its vocabulary (words and figures of speech), since pronunciation is probably not important here and grammar will be based on literature form of the language. To document the dialect, you need to design a documentation structure that will be best suitable for managing a vocabulary (glossary of terms).
People may want to use this documentation for learning the meaning of the word or acronym, to find correct word by its synonym or definition or to learn all the words that compose the domain.
For these user needs, wiki is indeed a good choice. How does it fit?
In good wiki system like Confluence or MediaWiki it is possible to:
- Create an article for each term.
- Define common structure of the articles in some template, so that they will contain some common sections, that can be used for aggregation.
- Easily add links to term definitions in other wiki articles.
- Build aggregate tables with term definitions and embed them in other documentation.
Currently I'm using Confluence for documenting information architecture and ubiquitous language definitions are part of it. Highest level of this documentation are domain articles. In every application there are multiple domains, e.g. security, payments etc. These domains are defined by a number of interactions of user with the system, which can be described via ubiquitous language, so I put definitions of these interactions in separate subpages, and definitions of terms introduced by these interactions in the subpages of interaction pages. I put aggregate tables on parent pages so it's possible to see, for example, of which scenarios consists the domain and which terms are defined in it.
When this documentation structure is done and I go to more detailed system specifications, I can simply refer to the IA and UL definitions of the scenarios e.g. "component A implements integration with system B to support interaction C (IA scenario link) by passing information about Z (UL link)".