While toying around with a glossary (original is [[ https://www.mediawiki.org/wiki/Help:Spec/glossary | mw:Help:Spec/glossary ]], alternative is [[ https://www.mediawiki.org/wiki/Help:Spec/glossary_test | mw:Help:Spec/glossary test ]], my idea was to use [[ https://www.mediawiki.org/wiki/Help:Spec/glossary/continuous_integration | Help:Spec/glossary/continuous integration ]]) which didn't work as expected. (Fixing {T65045} would make this work) So I started to wonder how I would like this to work, and how it would be best done together with the translate extension. To make a whole lot of small pages isn't a really good solution, as such glossaries are used only on a few pages, and should be treated together.
Assume a that a link can be made to the page, and it contains a fragment identifier, like `[[Help:Spec/glossary#continuous integration]]`. The //Hovercard// solution would find the link includes a hash mark (#), will then try to find an element identified by the hash mark, and climb up the parent until a child for the content is found. It will then include all following children from the content up to the next one with a valid identifier at the same level. The set of elements is then pruned to form a set for the hovercard instance.
Note that some styles of glossaries use a //dl// list, where the fragment is put inside a //span// in the //dt// element. The proposed algorithm will work in this case if only following elements are included if they don't contain a valid identifier on the same level. A common way to make the glossary puts the identifier in a separate //p// element before the //dt//, and that will fail. (On second thought, it will not fail.)
This will make it possible to have a single glossary page, and still be able to reference it with fragment identifiers, and the hovercard functionality will still work as expected.
It should probably be possible to use this together with {T136480}, and especially note that it is a solution to the long glossary pages.