Wikimedia Bugzilla is closed!

Could you please provide a specific example where this would be helpful?

Not sure, I understand the question. I rather wonder why there has not yet been a Wikibase glossary. Some terms tend to be really specific (and, sadly, sometimes a bit off their native meaning, e.g. "Rank", "Qualifier"). No one knows the developers intention to use a specific term better than the developers. Why create confusion by having people maintaining the Wikidata glossary guess about developer intentions?
Not in any way arguing against a project specific Wikidata glossary, but a basic technical glossary should be maintained by the developers only, and be part of the actual software documentation. That glossary, off any project specifics, should be used to give hint to translators.
Even more, for users interested in using the Wikibase software, an "external" glossary is just not as reliable because it most likely contains project specifics.
Another use-case is standardizing wording and phrasing between developers in respect to the actual code and its interfaces.
In addition, there are terms that are not visible in the UI but via APIs etc. - e.g.: "Fingerprint".
Finally, maintaining a Wikibase glossary would, at least a tiny little bit, ease the process of changing a term/expression since the glossary may be used to reference back to deprecated terms and promote new terms.

It is a fair idea looking at it basically.

*** Bug 47317 has been marked as a duplicate of this bug. ***

There is a glossary at https://www.wikidata.org/wiki/Wikidata:Glossary

It has existed from almost the beginning of the localization effort. It has although becoming a bit sloppy in some of the descriptions, it could need a cleanup.

A real problem with glossaries like this is that there is not one but several mental models, and they does not match up very well. You have the mental model of the developer which has his own idea which is often a very technical one. The you have the localization teams that tries to interpret the technical ideas in the local language, often with only the internationalized message as a clue to what the developer is trying to express. Then you have the actual user trying to interpret the localized messages, and often introducing his own (or her) own misinterpretations. To make the interpretations match up, and produce the same mental model, is a non-trivial task.

Add to this that Wikibase uses its own lingo that doesn't follow the usual semantic/linked data lingo, and you are in for some real problems.

Fix up the glossary, and use it while writing the messages and the descriptions. The descriptions are very important as they conceptualize the developers idea and lets the localization teams recreate their mental models. That reduce the chance for translation errors, thereby they will better communicate the correct mental model to the user.

Sorry, to long, just cleanup the glossary.

There was a glossary at meta, and later on when the glossary at Wikidata was made I described some of the problems that would arise when when tha community built one glossary on their understanding and the developers had another. Typically the English messages will be written by the devs, and also a first version of the qqq-messages, but later on the community will start to change the qqq-messages to make them fit with their glossary, and the translators will also use the glossary while localizing the messages. That will make the English messages and the localized messages diverge somewhat.

I think the correct solution is to identify where this is a problem and try to align the models used by the devs and the community. If the models they use diverge it creates a lot of problems.