projectdoc Toolbox

Glossary items are part of the domain glossary for the project. Glossaries support the team to use terms of the domain consistently in conversations and documentation.

Documentation Type


It is important for a project to establish a common understanding the terms of its core domain. It may also be helpful to compile definitions, designations, and rough sketches for terms of secondary domains. This provides the basis for preventing misunderstanding or misuse of terms in the documentation, code or communication.

Teams must not be scared to describe terms. In project it is usually not necessary and often impracticable to define with water-proofed clarity. Keep in mind that the goal is a common understanding which typically evolves during the course of the project. This is especially true for glossaries that are used within the project by the team and associated experts. It may call for a different approach if the glossary is publicly available.


The document type glossary item provides the following properties:


Please note that only information about specific properties is provided here. Common document property used by all document types are documented by Document Properties.


Allows to organize glossary items by a doctype specific type using Glossary Item Type.


A abbreviation commonly used for the term. Defaults to the short name.

Linguistic Information

Provide linguistic information, such as genus or pronunciation, for the term.

Word Type

Until 11.0


Replaced by the Linguistic Information property.

Helps to categorize a term to be a noun (concept) or a verb (process-word).


You may replace the selection macro with the Name List Macro and add other or additional word types.


Until 11.0


Replaced by the Relation property.

State the domain within which the term is used. Terms may be part of the problem or the solution domain. In complex situations terms may be associated with a specific area of a problem domain.

This property allows to group terms by their domains. Please note that the term should be unique within the project independent of its domain to avoid confusion.

The name of the domain may link to a document that describes this domain (and maybe list all of its terms). This document may by itself be of type glossary item. You may also choose to use the Name List Macro to reference to these documents that describe the domain.


Since 11.1


Since version 11.1 Domain has been removed and replaced by the relation. The relation existed prior to version 11.1 but did not provide its own doctype.

Within a given domain terms may be related. This relation may be defined by a relation name.

The name of the relation may link to a document that describes this relation (and maybe list all of its terms). You may also choose to use the Name List Macro to reference to these documents that describe the domain.

Related Terms

Since 11.1


Since version 11.1 used to pick closely related terms.

List terms with references to other closely related terms in this glossary.



Define the term within its domain.


While most document types use the description sections to inform the reader about what to expect from the document, the glossary item actually has the definition of the term as its description.

Also note that this section does not demand a formal definition. So it is allowed to come as close as possible to define the term in the current context of the project (recognition rule). Projects sometimes need to define a working hypothesis for a term. Therefore it is also ok to just give a rough sketch defined by the team and the domain experts.

For more information on this topic, please refer to Software Requirements & Specification by Michael A. Jackson.

To describe a term define its scope and differentiate it by a span. The span constricts the applicability of the term within its domain and scope.

While the domain is explicitly stated, the scope is not. The scope may be identical to the domain or some form of subdomain.


Until 11.0


Removed to simplify the usage of glossary items.

Specializations narrow the generalized definition by differentiation.

This section lists subdocuments of this doctype.

List of Related Terms

Automatically lists items that are associated to this term. The terms are picked from the Related Terms property.


List translations of the term in other languages. These translations must not be used in the documents, but may help translators of technical documents. Usually you may add a two column table here, with the name of the locale (ISO 639 / ISO 3166 code) as the key and the translation of the term as a value.


List terms that mean the opposite of the defined term.

This supports to relate the term to other terms in the domain. The table of antonyms is usually two columns: the key in the first column is the antonym term, the second column contains an optional note.


List terms that are different words for the same concept.

Synonyms must not be used in the documentation to avoid confusion. The table of synonyms has usually two columns: the key in the first column is the synonym term, the second column contains an optional note that explains, why this term is not used.

Differences to

Explain the differences to other terms that may be confused with the defined term. This supports to relate the term to other terms in the domain. Use a two-column table with the first column specifying the term and the second column explaining the differences to the defined term and notes.

Deprecated Forms

List the forms of the word that have been deprecated.

Add those words that have formerly been used for the term, but are now discouraged.List the deprecated term (first column) and the reason why it is deprecated (second column) in a table.

ID Parts

Describe how the term is used in identifiers of programming languages (class names, method names, etc.) or other text files.

This supports to name these constructs consistently throughout the project. The parts are only explicitly defined in the wiki, if they cannot be generated automatically. The rules may be checked by static analyzers. If such rules are applied, refer to them in the resource section of this document.


These are internal notes that are usually not exported and only visible to team members with write access.

But this is not a safe place to store sensible information. It is just a convenience for the reader to not be bothered with notes stored here for the authors for later use. The security level is about suppressing the representation by a CSS style. Therefore consider this as a convenience for the reader, not as a security tool.


The text of notes sections is also indexed.


For a document the references section contains pointers to resources that prove the statements of the document.

Often these proofs are not easily distinguishable from further information. In this case you may want to skip the reference section in favour for the resource list.


For further information please refer to References and Resources.


The resources section provides references to further information to the topic of the document.

This may be information on the internet provided by the resource or information in the team's information systems. Anything the reader of the resource might want to know, may be listed here.


For further information please refer to References and Resources.

Related Macros

The following macros help to display glossaries:

Index Card Macro
Renders transcluded content fetched from documents of a result set.
Index Entries Table Macro
Renders a table of index entries.

Alternatives are the generic Display Table Macro, Transclude Documents Macro, and Display List Macro.